<?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</release>
		<issued date="2023-02-17"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44267" id="CVE-2022-44267" title="CVE-2022-44267" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44268" id="CVE-2022-44268" title="CVE-2022-44268" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-13"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4743" id="CVE-2022-4743" title="CVE-2022-4743" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-09"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37704" id="CVE-2022-37704" title="CVE-2022-37704" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37705" id="CVE-2022-37705" title="CVE-2022-37705" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24998" id="CVE-2023-24998" title="CVE-2023-24998" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-02-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24963" id="CVE-2022-24963" title="CVE-2022-24963" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25147" id="CVE-2022-25147" title="CVE-2022-25147" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-03"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41704" id="CVE-2022-41704" title="CVE-2022-41704" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42890" id="CVE-2022-42890" title="CVE-2022-42890" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-02-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33641" id="CVE-2021-33641" title="CVE-2021-33641" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33642" id="CVE-2021-33642" title="CVE-2021-33642" type="cve"/>
		</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).
CVE-2021-33642:When a file is processed, an infinite loop occurs in next_inline() of the more_curly() function.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4904" id="CVE-2022-4904" title="CVE-2022-4904" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-09"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3650" id="CVE-2022-3650" title="CVE-2022-3650" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20032" id="CVE-2023-20032" title="CVE-2023-20032" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20052" id="CVE-2023-20052" title="CVE-2023-20052" type="cve"/>
		</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 [&quot;https://blog.clamav.net/&quot;].
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-16"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23471" id="CVE-2022-23471" title="CVE-2022-23471" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25153" id="CVE-2023-25153" title="CVE-2023-25153" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25173" id="CVE-2023-25173" title="CVE-2023-25173" type="cve"/>
		</references>
		<description>CVE-2022-23471:containerd is an open source container runtime. A bug was found in containerd'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'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'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.
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.
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's client library should check that application for a separate advisory and instructions. As a workaround, ensure that the `&quot;USER $USERNAME&quot;` Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to `ENTRYPOINT [&quot;su&quot;, &quot;-&quot;, &quot;user&quot;]` to allow `su` to properly set up supplementary groups.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-03"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4122" id="CVE-2021-4122" title="CVE-2021-4122" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-03"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43551" id="CVE-2022-43551" title="CVE-2022-43551" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43552" id="CVE-2022-43552" title="CVE-2022-43552" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23914" id="CVE-2023-23914" title="CVE-2023-23914" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23915" id="CVE-2023-23915" title="CVE-2023-23915" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23916" id="CVE-2023-23916" title="CVE-2023-23916" type="cve"/>
		</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.
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.
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.
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.
CVE-2023-23916:An allocation of resources without limits or throttling vulnerability exists in curl &lt;v7.88.0 based on the &quot;chained&quot; HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with differentalgorithms. The number of acceptable &quot;links&quot; in this &quot;decompression chain&quot; 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 &quot;malloc bomb&quot;, making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-06"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0401" id="CVE-2023-0401" title="CVE-2023-0401" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-06"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48337" id="CVE-2022-48337" title="CVE-2022-48337" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48338" id="CVE-2022-48338" title="CVE-2022-48338" type="cve"/>
		</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 &quot;etags -u *&quot; command (suggested in the etags documentation) in a situation where the current working directory has contents that depend on untrusted input.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-20"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40899" id="CVE-2022-40899" title="CVE-2022-40899" type="cve"/>
		</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>FusionOS</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>
				</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</release>
		<issued date="2023-02-20"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22490" id="CVE-2023-22490" title="CVE-2023-22490" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23946" id="CVE-2023-23946" title="CVE-2023-23946" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41903" id="CVE-2022-41903" title="CVE-2022-41903" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23521" id="CVE-2022-23521" title="CVE-2022-23521" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41953" id="CVE-2022-41953" title="CVE-2022-41953" type="cve"/>
		</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's filesystem within the malicious repository'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.
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.
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`.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-03"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0687" id="CVE-2023-0687" title="CVE-2023-0687" type="cve"/>
		</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's basically trusted input or input that needs an actual security flaw to be compromised or controlled.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-18"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43618" id="CVE-2021-43618" title="CVE-2021-43618" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-13"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-44716" id="CVE-2021-44716" title="CVE-2021-44716" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23772" id="CVE-2022-23772" title="CVE-2022-23772" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23773" id="CVE-2022-23773" title="CVE-2022-23773" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23806" id="CVE-2022-23806" title="CVE-2022-23806" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24921" id="CVE-2022-24921" title="CVE-2022-24921" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41717" id="CVE-2022-41717" title="CVE-2022-41717" type="cve"/>
		</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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0056" id="CVE-2023-0056" title="CVE-2023-0056" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25725" id="CVE-2023-25725" title="CVE-2023-25725" type="cve"/>
		</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.
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 &quot;request smuggling.&quot; 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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25193" id="CVE-2023-25193" title="CVE-2023-25193" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-21"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2006-2001" id="CVE-2006-2001" title="CVE-2006-2001" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36760" id="CVE-2022-36760" title="CVE-2022-36760" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37436" id="CVE-2022-37436" title="CVE-2022-37436" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25690" id="CVE-2023-25690" title="CVE-2023-25690" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27522" id="CVE-2023-27522" title="CVE-2023-27522" type="cve"/>
		</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.
CVE-2022-36760:Inconsistent Interpretation of HTTP Requests ('HTTP Request Smuggling') 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.
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.
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 &quot;^/here/(.*)&quot; &quot;http://example.com:8080/elsewhere?$1&quot;; [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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-18"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42004" id="CVE-2022-42004" title="CVE-2022-42004" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-03-18"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2014-125087" id="CVE-2014-125087" title="CVE-2014-125087" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-03-18"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28168" id="CVE-2021-28168" title="CVE-2021-28168" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46663" id="CVE-2022-46663" title="CVE-2022-46663" type="cve"/>
		</references>
		<description>CVE-2022-46663:In GNU Less before 609, crafted data can result in &quot;less -R&quot; not filtering ANSI escape sequences sent to the terminal.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="less" release="4.u1.fos23" version="590">
					<filename>less-590-4.u1.fos23.aarch64.rpm</filename>
				</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</release>
		<issued date="2023-02-16"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44617" id="CVE-2022-44617" title="CVE-2022-44617" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46285" id="CVE-2022-46285" title="CVE-2022-46285" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4883" id="CVE-2022-4883" title="CVE-2022-4883" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-16"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-36976" id="CVE-2021-36976" title="CVE-2021-36976" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47629" id="CVE-2022-47629" title="CVE-2022-47629" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-21"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27371" id="CVE-2023-27371" title="CVE-2023-27371" type="cve"/>
		</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 '\0' 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23009" id="CVE-2023-23009" title="CVE-2023-23009" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48281" id="CVE-2022-48281" title="CVE-2022-48281" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0795" id="CVE-2023-0795" title="CVE-2023-0795" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0796" id="CVE-2023-0796" title="CVE-2023-0796" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0797" id="CVE-2023-0797" title="CVE-2023-0797" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0798" id="CVE-2023-0798" title="CVE-2023-0798" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0799" id="CVE-2023-0799" title="CVE-2023-0799" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0800" id="CVE-2023-0800" title="CVE-2023-0800" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0801" id="CVE-2023-0801" title="CVE-2023-0801" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0802" id="CVE-2023-0802" title="CVE-2023-0802" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0803" id="CVE-2023-0803" title="CVE-2023-0803" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0804" id="CVE-2023-0804" title="CVE-2023-0804" type="cve"/>
		</references>
		<description>CVE-2022-48281:processCropSelections in tools/tiffcrop.c in LibTIFF through 4.5.0 has a heap-based buffer overflow (e.g., &quot;WRITE of size 307203&quot;) via a crafted TIFF image.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-07"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47952" id="CVE-2022-47952" title="CVE-2022-47952" type="cve"/>
		</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 &quot;Failed to open&quot; often indicates that a file does not exist, whereas &quot;does not refer to a network namespace path&quot; 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 &quot;we will report back to the user that the open() failed but the user has no way of knowing why it failed&quot;; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-07"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44792" id="CVE-2022-44792" title="CVE-2022-44792" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44793" id="CVE-2022-44793" title="CVE-2022-44793" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"/>
		</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.
CVE-2022-4450:The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &quot;name&quot; (e.g. &quot;CERTIFICATE&quot;), any header data and the payload data. If the function succeeds then the &quot;name_out&quot;, &quot;header&quot; and &quot;data&quot; 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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-16"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25136" id="CVE-2023-25136" title="CVE-2023-25136" type="cve"/>
		</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 &quot;remote code execution is theoretically possible.&quot;</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"/>
		</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.
CVE-2022-4450:The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &quot;name&quot; (e.g. &quot;CERTIFICATE&quot;), any header data and the payload data. If the function succeeds then the &quot;name_out&quot;, &quot;header&quot; and &quot;data&quot; 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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-16"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4338" id="CVE-2022-4338" title="CVE-2022-4338" type="cve"/>
		</references>
		<description>CVE-2022-4338:An integer underflow in Organization Specific TLV was found in various versions of OpenvSwitch.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-24"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47021" id="CVE-2022-47021" title="CVE-2022-47021" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3560" id="CVE-2022-3560" title="CVE-2022-3560" type="cve"/>
		</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 'pesign' group. However, the script doesn'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>FusionOS</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="pesign" release="4.u1.fos23" version="115">
					<filename>pesign-115-4.u1.fos23.aarch64.rpm</filename>
				</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>
				</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</release>
		<issued date="2023-02-16"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24056" id="CVE-2023-24056" title="CVE-2023-24056" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-21"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37337" id="CVE-2022-37337" title="CVE-2022-37337" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-16"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4603" id="CVE-2022-4603" title="CVE-2022-4603" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-27"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23931" id="CVE-2023-23931" title="CVE-2023-23931" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40898" id="CVE-2022-40898" title="CVE-2022-40898" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-02-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33621" id="CVE-2021-33621" title="CVE-2021-33621" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44566" id="CVE-2022-44566" title="CVE-2022-44566" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22794" id="CVE-2023-22794" title="CVE-2023-22794" type="cve"/>
		</references>
		<description>CVE-2022-44566:A denial of service vulnerability present in ActiveRecord'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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-03-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22796" id="CVE-2023-22796" title="CVE-2023-22796" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-02-16"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22799" id="CVE-2023-22799" title="CVE-2023-22799" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-03-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-03-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25857" id="CVE-2022-25857" title="CVE-2022-25857" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38749" id="CVE-2022-38749" title="CVE-2022-38749" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38750" id="CVE-2022-38750" title="CVE-2022-38750" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38751" id="CVE-2022-38751" title="CVE-2022-38751" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38752" id="CVE-2022-38752" title="CVE-2022-38752" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41854" id="CVE-2022-41854" title="CVE-2022-41854" type="cve"/>
		</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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-03-18"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22809" id="CVE-2023-22809" title="CVE-2023-22809" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27320" id="CVE-2023-27320" title="CVE-2023-27320" type="cve"/>
		</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 &quot;--&quot; argument that defeats a protection mechanism, e.g., an EDITOR='vim -- /path/to/extra/file' value.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-01-19"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4415" id="CVE-2022-4415" title="CVE-2022-4415" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="systemd" release="46.u7.fos23" version="249">
					<filename>systemd-249-46.u7.fos23.aarch64.rpm</filename>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-17"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48303" id="CVE-2022-48303" title="CVE-2022-48303" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-13"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47016" id="CVE-2022-47016" title="CVE-2022-47016" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42252" id="CVE-2022-42252" title="CVE-2022-42252" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43980" id="CVE-2021-43980" title="CVE-2021-43980" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-01-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22745" id="CVE-2023-22745" title="CVE-2023-22745" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-20"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0051" id="CVE-2023-0051" title="CVE-2023-0051" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0054" id="CVE-2023-0054" title="CVE-2023-0054" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0049" id="CVE-2023-0049" title="CVE-2023-0049" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0288" id="CVE-2023-0288" title="CVE-2023-0288" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47024" id="CVE-2022-47024" title="CVE-2022-47024" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0433" id="CVE-2023-0433" title="CVE-2023-0433" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1170" id="CVE-2023-1170" title="CVE-2023-1170" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1175" id="CVE-2023-1175" title="CVE-2023-1175" type="cve"/>
		</references>
		<description>CVE-2023-0051:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1144.
CVE-2023-0054:Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.1145.
CVE-2023-0049:Out-of-bounds Read in GitHub repository vim/vim prior to 9.0.1143.
CVE-2023-0288:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1189.
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.
CVE-2023-0433:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1225.
CVE-2023-1170:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1376.
CVE-2023-1175:Incorrect Calculation of Buffer Size in GitHub repository vim/vim prior to 9.0.1378.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-23"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3724" id="CVE-2022-3724" title="CVE-2022-3724" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0416" id="CVE-2023-0416" title="CVE-2023-0416" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0411" id="CVE-2023-0411" title="CVE-2023-0411" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0413" id="CVE-2023-0413" title="CVE-2023-0413" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0415" id="CVE-2023-0415" title="CVE-2023-0415" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0417" id="CVE-2023-0417" title="CVE-2023-0417" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4344" id="CVE-2022-4344" title="CVE-2022-4344" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4345" id="CVE-2022-4345" title="CVE-2022-4345" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0412" id="CVE-2023-0412" title="CVE-2023-0412" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1161" id="CVE-2023-1161" title="CVE-2023-1161" type="cve"/>
		</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
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
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
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
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
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
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
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
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
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-02-14"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0494" id="CVE-2023-0494" title="CVE-2023-0494" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-03-18"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41966" id="CVE-2022-41966" title="CVE-2022-41966" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1289" id="CVE-2023-1289" title="CVE-2023-1289" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1906" id="CVE-2023-1906" title="CVE-2023-1906" type="cve"/>
		</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 &quot;/tmp,&quot; 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.
CVE-2023-1906:A heap-based buffer overflow issue was discovered in ImageMagick'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1981" id="CVE-2023-1981" title="CVE-2023-1981" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27349" id="CVE-2023-27349" title="CVE-2023-27349" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27533" id="CVE-2023-27533" title="CVE-2023-27533" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27534" id="CVE-2023-27534" title="CVE-2023-27534" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27535" id="CVE-2023-27535" title="CVE-2023-27535" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27536" id="CVE-2023-27536" title="CVE-2023-27536" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27538" id="CVE-2023-27538" title="CVE-2023-27538" type="cve"/>
		</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 &quot;telnet options&quot; 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.
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.
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.
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'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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30630" id="CVE-2023-30630" title="CVE-2023-30630" type="cve"/>
		</references>
		<description>CVE-2023-30630:Dmidecode reports information about your system'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 &quot;signatures&quot; and add them to the kernel source code when needed.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28450" id="CVE-2023-28450" title="CVE-2023-28450" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28617" id="CVE-2023-28617" title="CVE-2023-28617" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2004" id="CVE-2023-2004" title="CVE-2023-2004" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24593" id="CVE-2023-24593" title="CVE-2023-24593" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25180" id="CVE-2023-25180" title="CVE-2023-25180" type="cve"/>
		</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's code was separated from GTK, so it can be used by software other than GNOME and has been developed in parallel ever since.
CVE-2023-25180:GLib is a bundle of three (formerly five) low-level system libraries written in C and developed mainly by GNOME. GLib'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26253" id="CVE-2023-26253" title="CVE-2023-26253" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0361" id="CVE-2023-0361" title="CVE-2023-0361" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25950" id="CVE-2023-25950" title="CVE-2023-25950" type="cve"/>
		</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's request. As a result, the attacker may obtain sensitive information or cause a denial-of-service (DoS) condition.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13867" id="CVE-2018-13867" title="CVE-2018-13867" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14031" id="CVE-2018-14031" title="CVE-2018-14031" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-16438" id="CVE-2018-16438" title="CVE-2018-16438" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-8396" id="CVE-2019-8396" title="CVE-2019-8396" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10812" id="CVE-2020-10812" title="CVE-2020-10812" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-37501" id="CVE-2021-37501" title="CVE-2021-37501" type="cve"/>
		</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.
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.
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.
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 &quot;Invalid write of size 2.&quot;
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2047" id="CVE-2022-2047" title="CVE-2022-2047" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2048" id="CVE-2022-2048" title="CVE-2022-2048" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1370" id="CVE-2023-1370" title="CVE-2023-1370" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36280" id="CVE-2022-36280" title="CVE-2022-36280" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4269" id="CVE-2022-4269" title="CVE-2022-4269" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48423" id="CVE-2022-48423" title="CVE-2022-48423" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48424" id="CVE-2022-48424" title="CVE-2022-48424" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48425" id="CVE-2022-48425" title="CVE-2022-48425" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0266" id="CVE-2023-0266" title="CVE-2023-0266" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1079" id="CVE-2023-1079" title="CVE-2023-1079" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1249" id="CVE-2023-1249" title="CVE-2023-1249" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1281" id="CVE-2023-1281" title="CVE-2023-1281" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1380" id="CVE-2023-1380" title="CVE-2023-1380" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1382" id="CVE-2023-1382" title="CVE-2023-1382" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1513" id="CVE-2023-1513" title="CVE-2023-1513" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1611" id="CVE-2023-1611" title="CVE-2023-1611" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1670" id="CVE-2023-1670" title="CVE-2023-1670" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1855" id="CVE-2023-1855" title="CVE-2023-1855" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1859" id="CVE-2023-1859" title="CVE-2023-1859" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1872" id="CVE-2023-1872" title="CVE-2023-1872" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1989" id="CVE-2023-1989" title="CVE-2023-1989" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1990" id="CVE-2023-1990" title="CVE-2023-1990" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1998" id="CVE-2023-1998" title="CVE-2023-1998" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2006" id="CVE-2023-2006" title="CVE-2023-2006" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28327" id="CVE-2023-28327" title="CVE-2023-28327" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28328" id="CVE-2023-28328" title="CVE-2023-28328" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28466" id="CVE-2023-28466" title="CVE-2023-28466" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30456" id="CVE-2023-30456" title="CVE-2023-30456" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30772" id="CVE-2023-30772" title="CVE-2023-30772" type="cve"/>
		</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 '/dev/dri/renderD128 (or Dxxx)'. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).
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 &quot;mirred&quot;) 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.
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.
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.
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.
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
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.
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 (&quot;coredump: Use the vma snapshot in fill_files_note&quot;) not applied yet, then kernel could be affected.
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 'tcf_exts_exec()' 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.
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.
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.
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.
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
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.
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.
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.
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
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.
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.
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.
CVE-2023-2006:A race condition was found in the Linux kernel'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.
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/
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.
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).
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12762" id="CVE-2020-12762" title="CVE-2020-12762" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0614" id="CVE-2023-0614" title="CVE-2023-0614" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26769" id="CVE-2023-26769" title="CVE-2023-26769" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28484" id="CVE-2023-28484" title="CVE-2023-28484" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29469" id="CVE-2023-29469" title="CVE-2023-29469" type="cve"/>
		</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.
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 '\0' value).</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-45985" id="CVE-2021-45985" title="CVE-2021-45985" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44370" id="CVE-2022-44370" title="CVE-2022-44370" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"/>
		</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' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function.
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' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1668" id="CVE-2023-1668" title="CVE-2023-1668" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40897" id="CVE-2022-40897" title="CVE-2022-40897" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24329" id="CVE-2023-24329" title="CVE-2023-24329" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36021" id="CVE-2022-36021" title="CVE-2022-36021" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36021" id="CVE-2022-36021" title="CVE-2022-36021" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28755" id="CVE-2023-28755" title="CVE-2023-28755" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28756" id="CVE-2023-28756" title="CVE-2023-28756" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28642" id="CVE-2023-28642" title="CVE-2023-28642" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24626" id="CVE-2023-24626" title="CVE-2023-24626" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29383" id="CVE-2023-29383" title="CVE-2023-29383" type="cve"/>
		</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 &quot;cat /etc/passwd&quot; shows a rogue user account.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46908" id="CVE-2022-46908" title="CVE-2022-46908" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28486" id="CVE-2023-28486" title="CVE-2023-28486" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28487" id="CVE-2023-28487" title="CVE-2023-28487" type="cve"/>
		</references>
		<description>CVE-2023-28486:Sudo before 1.9.13 does not escape control characters in log messages.
CVE-2023-28487:Sudo before 1.9.13 does not escape control characters in sudoreplay output.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1801" id="CVE-2023-1801" title="CVE-2023-1801" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28708" id="CVE-2023-28708" title="CVE-2023-28708" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1108" id="CVE-2023-1108" title="CVE-2023-1108" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1264" id="CVE-2023-1264" title="CVE-2023-1264" type="cve"/>
		</references>
		<description>CVE-2023-1264:NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1392.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1992" id="CVE-2023-1992" title="CVE-2023-1992" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1993" id="CVE-2023-1993" title="CVE-2023-1993" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1994" id="CVE-2023-1994" title="CVE-2023-1994" type="cve"/>
		</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
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
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1393" id="CVE-2023-1393" title="CVE-2023-1393" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-05-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4899" id="CVE-2022-4899" title="CVE-2022-4899" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1729" id="CVE-2023-1729" title="CVE-2023-1729" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3736 " id="CVE-2022-3736 " title="CVE-2022-3736 " type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3924" id="CVE-2022-3924" title="CVE-2022-3924" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3094" id="CVE-2022-3094" title="CVE-2022-3094" type="cve"/>
		</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. 
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.
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.
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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25815" id="CVE-2023-25815" title="CVE-2023-25815" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29007" id="CVE-2023-29007" title="CVE-2023-29007" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25652" id="CVE-2023-25652" title="CVE-2023-25652" type="cve"/>
		</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'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:\`.
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'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`.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29400" id="CVE-2023-29400" title="CVE-2023-29400" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24540" id="CVE-2023-24540" title="CVE-2023-24540" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24539" id="CVE-2023-24539" title="CVE-2023-24539" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24538" id="CVE-2023-24538" title="CVE-2023-24538" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24537" id="CVE-2023-24537" title="CVE-2023-24537" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24536" id="CVE-2023-24536" title="CVE-2023-24536" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24534" id="CVE-2023-24534" title="CVE-2023-24534" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24532" id="CVE-2023-24532" title="CVE-2023-24532" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41725" id="CVE-2022-41725" title="CVE-2022-41725" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41724" id="CVE-2022-41724" title="CVE-2022-41724" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41722" id="CVE-2022-41722" title="CVE-2022-41722" type="cve"/>
		</references>
		<description>CVE-2023-29400:Templates containing actions in unquoted HTML attributes (e.g. &quot;attr={{.}}&quot;) 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.
CVE-2023-24540:Not all valid JavaScript whitespace characters are considered to be whitespace. Templates containing whitespace characters outside of the character set &quot;\t\n\f\r\u0020\u2028\u2029&quot; in JavaScript contexts that also contain actions may not be properly sanitized during execution.
CVE-2023-24539:Angle brackets (&lt;&gt;) are not considered dangerous characters when inserted into CSS contexts. Templates containing multiple actions separated by a '/' character can result in unexpectedly closing the CSS context and allowing for injection of unexpected HTML, if executed with untrusted input.
CVE-2023-24538:Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected.
With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12.
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.
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=.
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.
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.
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.
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).
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.
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 &quot;a/../c:/b&quot; into the valid path &quot;c:\b&quot;. 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 &quot;.\c:\b&quot;.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1829" id="CVE-2023-1829" title="CVE-2023-1829" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4382" id="CVE-2022-4382" title="CVE-2022-4382" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0458" id="CVE-2023-0458" title="CVE-2023-0458" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2269" id="CVE-2023-2269" title="CVE-2023-2269" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2483" id="CVE-2023-2483" title="CVE-2023-2483" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31436" id="CVE-2023-31436" title="CVE-2023-31436" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2176" id="CVE-2023-2176" title="CVE-2023-2176" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2194" id="CVE-2023-2194" title="CVE-2023-2194" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2166" id="CVE-2023-2166" title="CVE-2023-2166" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2007" id="CVE-2023-2007" title="CVE-2023-2007" type="cve"/>
		</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.
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.
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 'rlim' variable and can be used to leak the contents.
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.
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.
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.
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.
CVE-2023-2194:An out-of-bounds write vulnerability was found in the Linux kernel's SLIMpro I2C device driver. The userspace &quot;data-&gt;block[0]&quot; 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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28625" id="CVE-2023-28625" title="CVE-2023-28625" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37434" id="CVE-2022-37434" title="CVE-2022-37434" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31484" id="CVE-2023-31484" title="CVE-2023-31484" type="cve"/>
		</references>
		<description>CVE-2023-31484:CPAN.pm before 2.35 does not verify TLS certificates when downloading distributions over HTTPS.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-02"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38023" id="CVE-2022-38023" title="CVE-2022-38023" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37966" id="CVE-2022-37966" title="CVE-2022-37966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37967" id="CVE-2022-37967" title="CVE-2022-37967" type="cve"/>
		</references>
		<description>CVE-2022-38023:Netlogon RPC Elevation of Privilege Vulnerability.
CVE-2022-37966:Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability
CVE-2022-37967:Windows Kerberos Elevation of Privilege Vulnerability</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34151" id="CVE-2023-34151" title="CVE-2023-34151" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34153" id="CVE-2023-34153" title="CVE-2023-34153" type="cve"/>
		</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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31130" id="CVE-2023-31130" title="CVE-2023-31130" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32067" id="CVE-2023-32067" title="CVE-2023-32067" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31124" id="CVE-2023-31124" title="CVE-2023-31124" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31147" id="CVE-2023-31147" title="CVE-2023-31147" type="cve"/>
		</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 &quot;0::00:00:00/2&quot; 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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2084" id="CVE-2022-2084" title="CVE-2022-2084" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1786" id="CVE-2023-1786" title="CVE-2023-1786" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-1197" id="CVE-2015-1197" title="CVE-2015-1197" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32324" id="CVE-2023-32324" title="CVE-2023-32324" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24805" id="CVE-2023-24805" title="CVE-2023-24805" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28322" id="CVE-2023-28322" title="CVE-2023-28322" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28320" id="CVE-2023-28320" title="CVE-2023-28320" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28321" id="CVE-2023-28321" title="CVE-2023-28321" type="cve"/>
		</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.
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.
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 &quot;Subject Alternative Name&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28879" id="CVE-2023-28879" title="CVE-2023-28879" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42003" id="CVE-2022-42003" title="CVE-2022-42003" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42004" id="CVE-2022-42004" title="CVE-2022-42004" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36518" id="CVE-2020-36518" title="CVE-2020-36518" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45685" id="CVE-2022-45685" title="CVE-2022-45685" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45693" id="CVE-2022-45693" title="CVE-2022-45693" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40149" id="CVE-2022-40149" title="CVE-2022-40149" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3141" id="CVE-2023-3141" title="CVE-2023-3141" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22998" id="CVE-2023-22998" title="CVE-2023-22998" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34256" id="CVE-2023-34256" title="CVE-2023-34256" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48502" id="CVE-2022-48502" title="CVE-2022-48502" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25012" id="CVE-2023-25012" title="CVE-2023-25012" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2985" id="CVE-2023-2985" title="CVE-2023-2985" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3111" id="CVE-2023-3111" title="CVE-2023-3111" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32233" id="CVE-2023-32233" title="CVE-2023-32233" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1015" id="CVE-2022-1015" title="CVE-2022-1015" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32233" id="CVE-2023-32233" title="CVE-2023-32233" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2124" id="CVE-2023-2124" title="CVE-2023-2124" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32269" id="CVE-2023-32269" title="CVE-2023-32269" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2002" id="CVE-2023-2002" title="CVE-2023-2002" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26544" id="CVE-2023-26544" title="CVE-2023-26544" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0459" id="CVE-2023-0459" title="CVE-2023-0459" type="cve"/>
		</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.
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).
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.
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.
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.
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.
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().
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.
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.
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.
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.
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.
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.
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.
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 &quot;access_ok&quot; check and pass a kernel pointer to copy_from_user(). This would allow an attacker to leak information.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2602" id="CVE-2023-2602" title="CVE-2023-2602" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2603" id="CVE-2023-2603" title="CVE-2023-2603" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30570" id="CVE-2023-30570" title="CVE-2023-30570" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1667" id="CVE-2023-1667" title="CVE-2023-1667" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2283" id="CVE-2023-2283" title="CVE-2023-2283" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1916" id="CVE-2023-1916" title="CVE-2023-1916" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2731" id="CVE-2023-2731" title="CVE-2023-2731" type="cve"/>
		</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.
CVE-2023-2731:A NULL pointer dereference flaw was found in Libtiff'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1017" id="CVE-2023-1017" title="CVE-2023-1017" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1018" id="CVE-2023-1018" title="CVE-2023-1018" type="cve"/>
		</references>
		<description>CVE-2023-1017:An out-of-bounds write vulnerability exists in TPM2.0'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.
CVE-2023-1018:An out-of-bounds read vulnerability exists in TPM2.0'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1999" id="CVE-2023-1999" title="CVE-2023-1999" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-16487" id="CVE-2018-16487" title="CVE-2018-16487" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-3721" id="CVE-2018-3721" title="CVE-2018-3721" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10744" id="CVE-2019-10744" title="CVE-2019-10744" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-8203" id="CVE-2020-8203" title="CVE-2020-8203" type="cve"/>
		</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.
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 &quot;Object&quot; via __proto__, causing the addition or modification of an existing property that will exist on all objects.
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.
CVE-2020-8203:Prototype pollution attack when using _.zipObjectDeep in lodash before 4.17.20.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47952" id="CVE-2022-47952" title="CVE-2022-47952" type="cve"/>
		</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 &quot;Failed to open&quot; often indicates that a file does not exist, whereas &quot;does not refer to a network namespace path&quot; 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 &quot;we will report back to the user that the open() failed but the user has no way of knowing why it failed&quot;; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-16869" id="CVE-2019-16869" title="CVE-2019-16869" type="cve"/>
		</references>
		<description>CVE-2019-16869:Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a &quot;Transfer-Encoding : chunked&quot; line), which leads to HTTP request smuggling.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26551" id="CVE-2023-26551" title="CVE-2023-26551" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26552" id="CVE-2023-26552" title="CVE-2023-26552" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26553" id="CVE-2023-26553" title="CVE-2023-26553" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26554" id="CVE-2023-26554" title="CVE-2023-26554" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26555" id="CVE-2023-26555" title="CVE-2023-26555" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26551" id="CVE-2023-26551" title="CVE-2023-26551" type="cve"/>
		</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.
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.
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.
CVE-2023-26554:mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write when adding a '\0' character. An adversary may be able to attack a client ntpq process, but cannot attack ntpd.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2953" id="CVE-2023-2953" title="CVE-2023-2953" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"/>
		</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 'n' 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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30861" id="CVE-2023-30861" title="CVE-2023-30861" type="cve"/>
		</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's `session` cookie to other clients. The severity depends on the application's use of the session and the proxy'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>FusionOS</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33733" id="CVE-2023-33733" title="CVE-2023-33733" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32681" id="CVE-2023-32681" title="CVE-2023-32681" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32762" id="CVE-2023-32762" title="CVE-2023-32762" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/,CVE-2023-32763" id=",CVE-2023-32763" title=",CVE-2023-32763" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24607" id="CVE-2023-24607" title="CVE-2023-24607" type="cve"/>
		</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.
,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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28856" id="CVE-2023-28856" title="CVE-2023-28856" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28856" id="CVE-2023-28856" title="CVE-2023-28856" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14628" id="CVE-2018-14628" title="CVE-2018-14628" type="cve"/>
		</references>
		<description>CVE-2018-14628:An information leak vulnerability was discovered in Samba'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33204" id="CVE-2023-33204" title="CVE-2023-33204" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0563" id="CVE-2022-0563" title="CVE-2022-0563" type="cve"/>
		</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 &quot;INPUTRC&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2609" id="CVE-2023-2609" title="CVE-2023-2609" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2610" id="CVE-2023-2610" title="CVE-2023-2610" type="cve"/>
		</references>
		<description>CVE-2023-2609:NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1531.
CVE-2023-2610:Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1532.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28204" id="CVE-2023-28204" title="CVE-2023-28204" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32373" id="CVE-2023-32373" title="CVE-2023-32373" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32409" id="CVE-2023-32409" title="CVE-2023-32409" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0668" id="CVE-2023-0668" title="CVE-2023-0668" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2855" id="CVE-2023-2855" title="CVE-2023-2855" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2856" id="CVE-2023-2856" title="CVE-2023-2856" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2857" id="CVE-2023-2857" title="CVE-2023-2857" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2858" id="CVE-2023-2858" title="CVE-2023-2858" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2879" id="CVE-2023-2879" title="CVE-2023-2879" type="cve"/>
		</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.
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
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
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
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
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3550" id="CVE-2022-3550" title="CVE-2022-3550" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-06-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33454" id="CVE-2021-33454" title="CVE-2021-33454" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33455" id="CVE-2021-33455" title="CVE-2021-33455" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33456" id="CVE-2021-33456" title="CVE-2021-33456" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33457" id="CVE-2021-33457" title="CVE-2021-33457" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33458" id="CVE-2021-33458" title="CVE-2021-33458" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33459" id="CVE-2021-33459" title="CVE-2021-33459" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33460" id="CVE-2021-33460" title="CVE-2021-33460" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33461" id="CVE-2021-33461" title="CVE-2021-33461" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33462" id="CVE-2021-33462" title="CVE-2021-33462" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33463" id="CVE-2021-33463" title="CVE-2021-33463" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33464" id="CVE-2021-33464" title="CVE-2021-33464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33465" id="CVE-2021-33465" title="CVE-2021-33465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33466" id="CVE-2021-33466" title="CVE-2021-33466" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33467" id="CVE-2021-33467" title="CVE-2021-33467" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33468" id="CVE-2021-33468" title="CVE-2021-33468" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30402" id="CVE-2023-30402" title="CVE-2023-30402" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31972" id="CVE-2023-31972" title="CVE-2023-31972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31973" id="CVE-2023-31973" title="CVE-2023-31973" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31974" id="CVE-2023-31974" title="CVE-2023-31974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31975" id="CVE-2023-31975" title="CVE-2023-31975" type="cve"/>
		</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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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
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.
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.
CVE-2023-31974:yasm v1.3.0 was discovered to contain a use after free via the function error at /nasm/nasm-pp.c.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-07-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35737" id="CVE-2022-35737" title="CVE-2022-35737" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23840" id="CVE-2021-23840" title="CVE-2021-23840" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-07-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9840" id="CVE-2016-9840" title="CVE-2016-9840" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9841" id="CVE-2016-9841" title="CVE-2016-9841" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9842" id="CVE-2016-9842" title="CVE-2016-9842" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9843" id="CVE-2016-9843" title="CVE-2016-9843" type="cve"/>
		</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.
CVE-2016-9841:inffast.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2911" id="CVE-2023-2911" title="CVE-2023-2911" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2828" id="CVE-2023-2828" title="CVE-2023-2828" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33201" id="CVE-2023-33201" title="CVE-2023-33201" type="cve"/>
		</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's Subject Name into an LDAP search filter without any escaping, which leads to an LDAP injection vulnerability.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34241" id="CVE-2023-34241" title="CVE-2023-34241" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-25969" id="CVE-2020-25969" title="CVE-2020-25969" type="cve"/>
		</references>
		<description>CVE-2020-25969:gnuplot v5.5 was discovered to contain a buffer overflow via the function plotrequest().</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29402" id="CVE-2023-29402" title="CVE-2023-29402" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29403" id="CVE-2023-29403" title="CVE-2023-29403" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29404" id="CVE-2023-29404" title="CVE-2023-29404" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29405" id="CVE-2023-29405" title="CVE-2023-29405" type="cve"/>
		</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).
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.
CVE-2023-29404:he go command may execute arbitrary code at build time when using cgo. This may occur when running &quot;go get&quot; 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 &quot;#cgo LDFLAGS&quot; 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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2976" id="CVE-2023-2976" title="CVE-2023-2976" type="cve"/>
		</references>
		<description>CVE-2023-2976:Use of Java'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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3389" id="CVE-2023-3389" title="CVE-2023-3389" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3090" id="CVE-2023-3090" title="CVE-2023-3090" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3327" id="CVE-2023-3327" title="CVE-2023-3327" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35823" id="CVE-2023-35823" title="CVE-2023-35823" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35824" id="CVE-2023-35824" title="CVE-2023-35824" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3006" id="CVE-2023-3006" title="CVE-2023-3006" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31084" id="CVE-2023-31084" title="CVE-2023-31084" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35828" id="CVE-2023-35828" title="CVE-2023-35828" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35788" id="CVE-2023-35788" title="CVE-2023-35788" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3358" id="CVE-2023-3358" title="CVE-2023-3358" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48502" id="CVE-2022-48502" title="CVE-2022-48502" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33288" id="CVE-2023-33288" title="CVE-2023-33288" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2985" id="CVE-2023-2985" title="CVE-2023-2985" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3161" id="CVE-2023-3161" title="CVE-2023-3161" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3212" id="CVE-2023-3212" title="CVE-2023-3212" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3268" id="CVE-2023-3268" title="CVE-2023-3268" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35829" id="CVE-2023-35829" title="CVE-2023-35829" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3141" id="CVE-2023-3141" title="CVE-2023-3141" type="cve"/>
		</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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2023-3358:A null pointer dereference was found in the Linux kernel's Integrated Sensor Hub (ISH) driver. This issue could allow a local user to crash the system.
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.
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.
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.
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.
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.
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.
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.
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>FusionOS</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.40.0.117.u69.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.40.0.117.u69.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.40.0.117.u69.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.40.0.117.u69.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.40.0.117.u69.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.40.0.117.u69.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.40.0.117.u69.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.40.0.117.u69.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.40.0.117.u69.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.40.0.117.u69.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.40.0.117.u69.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.40.0.117.u69.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.40.0.117.u69.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.40.0.117.u69.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.40.0.117.u69.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.40.0.117.u69.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.40.0.117.u69.fos23.aarch64.rpm</filename>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35789" id="CVE-2023-35789" title="CVE-2023-35789" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26965" id="CVE-2023-26965" title="CVE-2023-26965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3316" id="CVE-2023-3316" title="CVE-2023-3316" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25433" id="CVE-2023-25433" title="CVE-2023-25433" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26966" id="CVE-2023-26966" title="CVE-2023-26966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2908" id="CVE-2023-2908" title="CVE-2023-2908" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3576" id="CVE-2023-3576" title="CVE-2023-3576" type="cve"/>
		</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.
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.
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.
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.
CVE-2023-2908:A null pointer dereference issue was found in Libtiff'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.
CVE-2023-3576:A vulnerability was found in libtiff where a memory leak exists in tools/tiffcrop.c</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29491" id="CVE-2023-29491" title="CVE-2023-29491" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"/>
		</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.
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' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31486" id="CVE-2023-31486" title="CVE-2023-31486" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36617" id="CVE-2023-36617" title="CVE-2023-36617" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34454" id="CVE-2023-34454" title="CVE-2023-34454" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34455" id="CVE-2023-34455" title="CVE-2023-34455" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1672" id="CVE-2023-1672" title="CVE-2023-1672" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="tang" release="3.u2.fos23" version="7">
					<filename>tang-7-3.u2.fos23.aarch64.rpm</filename>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32700" id="CVE-2023-32700" title="CVE-2023-32700" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-07-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0667" id="CVE-2023-0667" title="CVE-2023-0667" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2952" id="CVE-2023-2952" title="CVE-2023-2952" type="cve"/>
		</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
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3428" id="CVE-2023-3428" title="CVE-2023-3428" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34474" id="CVE-2023-34474" title="CVE-2023-34474" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34475" id="CVE-2023-34475" title="CVE-2023-34475" type="cve"/>
		</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.
CVE-2023-34474:A heap-based buffer overflow issue was discovered in ImageMagick'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.
CVE-2023-34475:A heap use after free issue was discovered in ImageMagick'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37464" id="CVE-2023-37464" title="CVE-2023-37464" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32001" id="CVE-2023-32001" title="CVE-2023-32001" type="cve"/>
		</references>
		<description>CVE-2023-32001:libcurl can be told to save cookie, HSTS and/or alt-svc data to files. When
doing this, it called `stat()` followed by `fopen()` in a way that made it
vulnerable to a TOCTOU race condition problem.
By exploiting this flaw, an attacker could trick the victim to create or
overwrite protected files holding this data in ways it was not intended to.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34969" id="CVE-2023-34969" title="CVE-2023-34969" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-44648" id="CVE-2021-44648" title="CVE-2021-44648" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2976" id="CVE-2023-2976" title="CVE-2023-2976" type="cve"/>
		</references>
		<description>CVE-2023-2976:Use of Java'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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38403" id="CVE-2023-38403" title="CVE-2023-38403" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3117" id="CVE-2023-3117" title="CVE-2023-3117" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3390" id="CVE-2023-3390" title="CVE-2023-3390" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45886" id="CVE-2022-45886" title="CVE-2022-45886" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3338" id="CVE-2023-3338" title="CVE-2023-3338" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3220" id="CVE-2023-3220" title="CVE-2023-3220" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31248" id="CVE-2023-31248" title="CVE-2023-31248" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3567" id="CVE-2023-3567" title="CVE-2023-3567" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2163" id="CVE-2023-2163" title="CVE-2023-2163" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35001" id="CVE-2023-35001" title="CVE-2023-35001" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32248" id="CVE-2023-32248" title="CVE-2023-32248" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32255" id="CVE-2023-32255" title="CVE-2023-32255" type="cve"/>
		</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.
CVE-2023-3390:A use-after-free vulnerability was found in the Linux kernel's netfilter subsystem in net/netfilter/nf_tables_api.c.
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.
We recommend upgrading past commit 1240eb93f0616b21c675416516ff3d74798fdc97.
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.
CVE-2023-3338:A null pointer dereference flaw was found in the Linux kernel's DECnet networking protocol. This issue could allow a remote user to crash the system.
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.
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
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.
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.
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
CVE-2023-32248:A flaw was found in the Linux kernel'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.
CVE-2023-32255:Linux Kernel ksmbd Session Setup Memory Leak Denial-of-Service Vulnerability</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3138" id="CVE-2023-3138" title="CVE-2023-3138" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39976" id="CVE-2023-39976" title="CVE-2023-39976" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38288" id="CVE-2023-38288" title="CVE-2023-38288" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38289" id="CVE-2023-38289" title="CVE-2023-38289" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35945" id="CVE-2023-35945" title="CVE-2023-35945" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38408" id="CVE-2023-38408" title="CVE-2023-38408" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"/>
		</references>
		<description>CVE-2023-3817:Issue summary: 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.
The function DH_check() performs various checks on DH parameters. After fixing
CVE-2023-3446 it was discovered that a large q parameter value can also trigger
an overly long computation during some of these checks. A correct q value,
if present, cannot be larger than the modulus p parameter, thus it is
unnecessary to perform these checks if q is larger than p.
An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulnerable to a Denial of Service attack.
The function DH_check() is itself called by a number of other OpenSSL functions.
An application calling any of those other functions may similarly be affected.
The other functions affected by this are DH_check_ex() and
EVP_PKEY_param_check().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
when using the &quot;-check&quot; option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2023-3446:Issue summary: 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.
The function DH_check() performs various checks on DH parameters. One of those
checks confirms that the modulus ('p' parameter) is not too large. Trying to use
a very large modulus is slow and OpenSSL will not normally use a modulus which
is over 10,000 bits in length.
However the DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus value
even if it has already been found to be too large.
An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulernable to a Denial of Service attack.
The function DH_check() is itself called by a number of other OpenSSL functions.
An application calling any of those other functions may similarly be affected.
The other functions affected by this are DH_check_ex() and
EVP_PKEY_param_check().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
when using the '-check' option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41409" id="CVE-2022-41409" title="CVE-2022-41409" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31486" id="CVE-2023-31486" title="CVE-2023-31486" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31484" id="CVE-2023-31484" title="CVE-2023-31484" type="cve"/>
		</references>
		<description>CVE-2023-31484:CPAN.pm before 2.35 does not verify TLS certificates when downloading distributions over HTTPS.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41946" id="CVE-2022-41946" title="CVE-2022-41946" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4016" id="CVE-2023-4016" title="CVE-2023-4016" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37920" id="CVE-2023-37920" title="CVE-2023-37920" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23491" id="CVE-2022-23491" title="CVE-2022-23491" type="cve"/>
		</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 &quot;e-Tugra&quot; root certificates. e-Tugra'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 &quot;e-Tugra&quot; from the root store.
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 &quot;TrustCor&quot; from the root store. These are in the process of being removed from Mozilla's trust store. TrustCor's root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor's ownership also operated a business that produced spyware. Conclusions of Mozilla's investigation can be found in the linked google group discussion.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40896" id="CVE-2022-40896" title="CVE-2022-40896" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28370" id="CVE-2023-28370" title="CVE-2023-28370" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23934" id="CVE-2023-23934" title="CVE-2023-23934" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25577" id="CVE-2023-25577" title="CVE-2023-25577" type="cve"/>
		</references>
		<description>CVE-2023-23934:Werkzeug is a comprehensive WSGI web application library. Browsers may allow &quot;nameless&quot; 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.
CVE-2023-25577:Werkzeug is a comprehensive WSGI web application library. Prior to version 2.2.3, Werkzeug'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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2007-4559" id="CVE-2007-4559" title="CVE-2007-4559" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0664" id="CVE-2023-0664" title="CVE-2023-0664" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2861" id="CVE-2023-2861" title="CVE-2023-2861" type="cve"/>
		</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's Windows installer via repair custom actions to elevate their privileges on the system.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28362" id="CVE-2023-28362" title="CVE-2023-28362" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2127" id="CVE-2022-2127" title="CVE-2022-2127" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3347" id="CVE-2023-3347" title="CVE-2023-3347" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34966" id="CVE-2023-34966" title="CVE-2023-34966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34967" id="CVE-2023-34967" title="CVE-2023-34967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34968" id="CVE-2023-34968" title="CVE-2023-34968" type="cve"/>
		</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.
CVE-2023-3347:A vulnerability was found in Samba's SMB2 packet signing mechanism. The SMB2 packet signing is not enforced if an admin configured &quot;server signing = required&quot; 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.
CVE-2023-34966:An infinite loop vulnerability was found in Samba'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.
CVE-2023-34967:A Type Confusion vulnerability was found in Samba'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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25399" id="CVE-2023-25399" title="CVE-2023-25399" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-0737" id="CVE-2018-0737" title="CVE-2018-0737" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23840" id="CVE-2021-23840" title="CVE-2021-23840" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36191" id="CVE-2023-36191" title="CVE-2023-36191" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9840" id="CVE-2016-9840" title="CVE-2016-9840" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9841" id="CVE-2016-9841" title="CVE-2016-9841" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9842" id="CVE-2016-9842" title="CVE-2016-9842" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9843" id="CVE-2016-9843" title="CVE-2016-9843" type="cve"/>
		</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.
CVE-2016-9841:inffast.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3648" id="CVE-2023-3648" title="CVE-2023-3648" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-08-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37732" id="CVE-2023-37732" title="CVE-2023-37732" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30577" id="CVE-2023-30577" title="CVE-2023-30577" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46174" id="CVE-2021-46174" title="CVE-2021-46174" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1972" id="CVE-2023-1972" title="CVE-2023-1972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48064" id="CVE-2022-48064" title="CVE-2022-48064" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4285" id="CVE-2022-4285" title="CVE-2022-4285" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47696" id="CVE-2022-47696" title="CVE-2022-47696" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47011" id="CVE-2022-47011" title="CVE-2022-47011" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47008" id="CVE-2022-47008" title="CVE-2022-47008" type="cve"/>
		</references>
		<description>CVE-2021-46174:Heap-based Buffer Overflow in function bfd_getl32 in Binutils objdump 3.37.
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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-1197" id="CVE-2015-1197" title="CVE-2015-1197" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48554" id="CVE-2022-48554" title="CVE-2022-48554" type="cve"/>
		</references>
		<description>CVE-2022-48554:File before 5.43 has an stack-based buffer over-read in file_copystr in funcs.c. NOTE: &quot;File&quot; is the name of an Open Source project.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22219" id="CVE-2020-22219" title="CVE-2020-22219" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4156" id="CVE-2023-4156" title="CVE-2023-4156" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39128" id="CVE-2023-39128" title="CVE-2023-39128" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38559" id="CVE-2023-38559" title="CVE-2023-38559" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29406" id="CVE-2023-29406" title="CVE-2023-29406" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40225" id="CVE-2023-40225" title="CVE-2023-40225" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47022" id="CVE-2022-47022" title="CVE-2022-47022" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40305" id="CVE-2023-40305" title="CVE-2023-40305" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20593" id="CVE-2023-20593" title="CVE-2023-20593" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4128" id="CVE-2023-4128" title="CVE-2023-4128" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4133" id="CVE-2023-4133" title="CVE-2023-4133" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4134" id="CVE-2023-4134" title="CVE-2023-4134" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4132" id="CVE-2023-4132" title="CVE-2023-4132" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3867" id="CVE-2023-3867" title="CVE-2023-3867" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4147" id="CVE-2023-4147" title="CVE-2023-4147" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3772" id="CVE-2023-3772" title="CVE-2023-3772" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3863" id="CVE-2023-3863" title="CVE-2023-3863" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3611" id="CVE-2023-3611" title="CVE-2023-3611" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38426" id="CVE-2023-38426" title="CVE-2023-38426" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3609" id="CVE-2023-3609" title="CVE-2023-3609" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21255" id="CVE-2023-21255" title="CVE-2023-21255" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38428" id="CVE-2023-38428" title="CVE-2023-38428" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3776" id="CVE-2023-3776" title="CVE-2023-3776" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4004" id="CVE-2023-4004" title="CVE-2023-4004" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38427" id="CVE-2023-38427" title="CVE-2023-38427" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38429" id="CVE-2023-38429" title="CVE-2023-38429" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38430" id="CVE-2023-38430" title="CVE-2023-38430" type="cve"/>
		</references>
		<description>CVE-2023-20593:An issue in “Zen 2” CPUs, under specific microarchitectural circumstances, may allow an attacker to potentially access sensitive information.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2023-3611:An out-of-bounds write vulnerability in the Linux kernel's net/sched: sch_qfq component can be exploited to achieve local privilege escalation.
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.
We recommend upgrading past commit 3e337087c3b5805fe0b8a46ba622a962880b5d64.
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's name_len is larger than the tag length.
CVE-2023-3609:A use-after-free vulnerability in the Linux kernel's net/sched: cls_u32 component can be exploited to achieve local privilege escalation.
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.
We recommend upgrading past commit 04c55383fa5689357bcdd2c8036725a55ed632bc.
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.
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.
CVE-2023-3776:A use-after-free vulnerability in the Linux kernel's net/sched: cls_fw component can be exploited to achieve local privilege escalation.
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.
We recommend upgrading past commit 0323bce598eea038714f941ce2b22541c46d488f.
CVE-2023-4004:A use-after-free flaw was found in the Linux kernel'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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36054" id="CVE-2023-36054" title="CVE-2023-36054" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38633" id="CVE-2023-38633" title="CVE-2023-38633" type="cve"/>
		</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=&quot;.?../../../../../../../../../../etc/passwd&quot; in an xi:include element.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40090" id="CVE-2022-40090" title="CVE-2022-40090" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3618" id="CVE-2023-3618" title="CVE-2023-3618" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48522" id="CVE-2022-48522" title="CVE-2022-48522" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3301" id="CVE-2023-3301" title="CVE-2023-3301" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3180" id="CVE-2023-3180" title="CVE-2023-3180" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-25786" id="CVE-2021-25786" title="CVE-2021-25786" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32573" id="CVE-2023-32573" title="CVE-2023-32573" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24834" id="CVE-2022-24834" title="CVE-2022-24834" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24834" id="CVE-2022-24834" title="CVE-2022-24834" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2157" id="CVE-2023-2157" title="CVE-2023-2157" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3195" id="CVE-2023-3195" title="CVE-2023-3195" type="cve"/>
		</references>
		<description>CVE-2023-2157:A heap-based buffer overflow vulnerability was found in the ImageMagick package that can lead to the application crashing.
CVE-2023-3195:A stack-based buffer overflow issue was found in ImageMagick'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-37533" id="CVE-2021-37533" title="CVE-2021-37533" type="cve"/>
		</references>
		<description>CVE-2021-37533:Prior to Apache Commons Net 3.9.0, Net'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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38398" id="CVE-2022-38398" title="CVE-2022-38398" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38648" id="CVE-2022-38648" title="CVE-2022-38648" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40146" id="CVE-2022-40146" title="CVE-2022-40146" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44729" id="CVE-2022-44729" title="CVE-2022-44729" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44730" id="CVE-2022-44730" title="CVE-2022-44730" type="cve"/>
		</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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47007" id="CVE-2022-47007" title="CVE-2022-47007" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47010" id="CVE-2022-47010" title="CVE-2022-47010" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48063" id="CVE-2022-48063" title="CVE-2022-48063" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44840" id="CVE-2022-44840" title="CVE-2022-44840" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47695" id="CVE-2022-47695" title="CVE-2022-47695" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48065" id="CVE-2022-48065" title="CVE-2022-48065" type="cve"/>
		</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.
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.
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.
CVE-2022-44840:Heap buffer overflow vulnerability in binutils readelf before 2.40 via function find_section_in_set in file readelf.c.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48174" id="CVE-2022-48174" title="CVE-2022-48174" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20197" id="CVE-2023-20197" title="CVE-2023-20197" type="cve"/>
		</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.
 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.
 For a description of this vulnerability, see the ClamAV blog .</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46310" id="CVE-2021-46310" title="CVE-2021-46310" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46312" id="CVE-2021-46312" title="CVE-2021-46312" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15663" id="CVE-2020-15663" title="CVE-2020-15663" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15664" id="CVE-2020-15664" title="CVE-2020-15664" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15665" id="CVE-2020-15665" title="CVE-2020-15665" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15666" id="CVE-2020-15666" title="CVE-2020-15666" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15667" id="CVE-2020-15667" title="CVE-2020-15667" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15668" id="CVE-2020-15668" title="CVE-2020-15668" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15670" id="CVE-2020-15670" title="CVE-2020-15670" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15673" id="CVE-2020-15673" title="CVE-2020-15673" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15674" id="CVE-2020-15674" title="CVE-2020-15674" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15675" id="CVE-2020-15675" title="CVE-2020-15675" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15676" id="CVE-2020-15676" title="CVE-2020-15676" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15677" id="CVE-2020-15677" title="CVE-2020-15677" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15678" id="CVE-2020-15678" title="CVE-2020-15678" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15680" id="CVE-2020-15680" title="CVE-2020-15680" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15681" id="CVE-2020-15681" title="CVE-2020-15681" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15682" id="CVE-2020-15682" title="CVE-2020-15682" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15683" id="CVE-2020-15683" title="CVE-2020-15683" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15684" id="CVE-2020-15684" title="CVE-2020-15684" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-16012" id="CVE-2020-16012" title="CVE-2020-16012" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-16044" id="CVE-2020-16044" title="CVE-2020-16044" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26950" id="CVE-2020-26950" title="CVE-2020-26950" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26951" id="CVE-2020-26951" title="CVE-2020-26951" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26953" id="CVE-2020-26953" title="CVE-2020-26953" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26956" id="CVE-2020-26956" title="CVE-2020-26956" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26958" id="CVE-2020-26958" title="CVE-2020-26958" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26959" id="CVE-2020-26959" title="CVE-2020-26959" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26960" id="CVE-2020-26960" title="CVE-2020-26960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26961" id="CVE-2020-26961" title="CVE-2020-26961" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26962" id="CVE-2020-26962" title="CVE-2020-26962" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26965" id="CVE-2020-26965" title="CVE-2020-26965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26966" id="CVE-2020-26966" title="CVE-2020-26966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26968" id="CVE-2020-26968" title="CVE-2020-26968" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26969" id="CVE-2020-26969" title="CVE-2020-26969" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26971" id="CVE-2020-26971" title="CVE-2020-26971" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26972" id="CVE-2020-26972" title="CVE-2020-26972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26973" id="CVE-2020-26973" title="CVE-2020-26973" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26974" id="CVE-2020-26974" title="CVE-2020-26974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26976" id="CVE-2020-26976" title="CVE-2020-26976" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26978" id="CVE-2020-26978" title="CVE-2020-26978" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26979" id="CVE-2020-26979" title="CVE-2020-26979" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35111" id="CVE-2020-35111" title="CVE-2020-35111" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35113" id="CVE-2020-35113" title="CVE-2020-35113" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35114" id="CVE-2020-35114" title="CVE-2020-35114" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23953" id="CVE-2021-23953" title="CVE-2021-23953" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23954" id="CVE-2021-23954" title="CVE-2021-23954" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23955" id="CVE-2021-23955" title="CVE-2021-23955" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23956" id="CVE-2021-23956" title="CVE-2021-23956" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23958" id="CVE-2021-23958" title="CVE-2021-23958" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23960" id="CVE-2021-23960" title="CVE-2021-23960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23961" id="CVE-2021-23961" title="CVE-2021-23961" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23962" id="CVE-2021-23962" title="CVE-2021-23962" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23963" id="CVE-2021-23963" title="CVE-2021-23963" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23964" id="CVE-2021-23964" title="CVE-2021-23964" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23965" id="CVE-2021-23965" title="CVE-2021-23965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23968" id="CVE-2021-23968" title="CVE-2021-23968" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23969" id="CVE-2021-23969" title="CVE-2021-23969" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23970" id="CVE-2021-23970" title="CVE-2021-23970" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23971" id="CVE-2021-23971" title="CVE-2021-23971" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23972" id="CVE-2021-23972" title="CVE-2021-23972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23973" id="CVE-2021-23973" title="CVE-2021-23973" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23974" id="CVE-2021-23974" title="CVE-2021-23974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23975" id="CVE-2021-23975" title="CVE-2021-23975" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23978" id="CVE-2021-23978" title="CVE-2021-23978" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23979" id="CVE-2021-23979" title="CVE-2021-23979" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23981" id="CVE-2021-23981" title="CVE-2021-23981" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23982" id="CVE-2021-23982" title="CVE-2021-23982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23983" id="CVE-2021-23983" title="CVE-2021-23983" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23984" id="CVE-2021-23984" title="CVE-2021-23984" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23985" id="CVE-2021-23985" title="CVE-2021-23985" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23986" id="CVE-2021-23986" title="CVE-2021-23986" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23987" id="CVE-2021-23987" title="CVE-2021-23987" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23988" id="CVE-2021-23988" title="CVE-2021-23988" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23994" id="CVE-2021-23994" title="CVE-2021-23994" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23995" id="CVE-2021-23995" title="CVE-2021-23995" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23996" id="CVE-2021-23996" title="CVE-2021-23996" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23997" id="CVE-2021-23997" title="CVE-2021-23997" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23998" id="CVE-2021-23998" title="CVE-2021-23998" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23999" id="CVE-2021-23999" title="CVE-2021-23999" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24000" id="CVE-2021-24000" title="CVE-2021-24000" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24001" id="CVE-2021-24001" title="CVE-2021-24001" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24002" id="CVE-2021-24002" title="CVE-2021-24002" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29944" id="CVE-2021-29944" title="CVE-2021-29944" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29945" id="CVE-2021-29945" title="CVE-2021-29945" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29946" id="CVE-2021-29946" title="CVE-2021-29946" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29947" id="CVE-2021-29947" title="CVE-2021-29947" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29952" id="CVE-2021-29952" title="CVE-2021-29952" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29953" id="CVE-2021-29953" title="CVE-2021-29953" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29955" id="CVE-2021-29955" title="CVE-2021-29955" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29959" id="CVE-2021-29959" title="CVE-2021-29959" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29960" id="CVE-2021-29960" title="CVE-2021-29960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29961" id="CVE-2021-29961" title="CVE-2021-29961" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29964" id="CVE-2021-29964" title="CVE-2021-29964" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29965" id="CVE-2021-29965" title="CVE-2021-29965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29966" id="CVE-2021-29966" title="CVE-2021-29966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29967" id="CVE-2021-29967" title="CVE-2021-29967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29970" id="CVE-2021-29970" title="CVE-2021-29970" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29972" id="CVE-2021-29972" title="CVE-2021-29972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29974" id="CVE-2021-29974" title="CVE-2021-29974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29975" id="CVE-2021-29975" title="CVE-2021-29975" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29976" id="CVE-2021-29976" title="CVE-2021-29976" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29977" id="CVE-2021-29977" title="CVE-2021-29977" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29980" id="CVE-2021-29980" title="CVE-2021-29980" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29981" id="CVE-2021-29981" title="CVE-2021-29981" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29982" id="CVE-2021-29982" title="CVE-2021-29982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29984" id="CVE-2021-29984" title="CVE-2021-29984" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29985" id="CVE-2021-29985" title="CVE-2021-29985" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29986" id="CVE-2021-29986" title="CVE-2021-29986" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29987" id="CVE-2021-29987" title="CVE-2021-29987" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29988" id="CVE-2021-29988" title="CVE-2021-29988" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29989" id="CVE-2021-29989" title="CVE-2021-29989" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29990" id="CVE-2021-29990" title="CVE-2021-29990" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29991" id="CVE-2021-29991" title="CVE-2021-29991" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-30547" id="CVE-2021-30547" title="CVE-2021-30547" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32810" id="CVE-2021-32810" title="CVE-2021-32810" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38491" id="CVE-2021-38491" title="CVE-2021-38491" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38493" id="CVE-2021-38493" title="CVE-2021-38493" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38494" id="CVE-2021-38494" title="CVE-2021-38494" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38496" id="CVE-2021-38496" title="CVE-2021-38496" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38497" id="CVE-2021-38497" title="CVE-2021-38497" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38498" id="CVE-2021-38498" title="CVE-2021-38498" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38499" id="CVE-2021-38499" title="CVE-2021-38499" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38500" id="CVE-2021-38500" title="CVE-2021-38500" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38501" id="CVE-2021-38501" title="CVE-2021-38501" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38503" id="CVE-2021-38503" title="CVE-2021-38503" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38504" id="CVE-2021-38504" title="CVE-2021-38504" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38505" id="CVE-2021-38505" title="CVE-2021-38505" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38506" id="CVE-2021-38506" title="CVE-2021-38506" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38507" id="CVE-2021-38507" title="CVE-2021-38507" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38508" id="CVE-2021-38508" title="CVE-2021-38508" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38509" id="CVE-2021-38509" title="CVE-2021-38509" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38510" id="CVE-2021-38510" title="CVE-2021-38510" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4140" id="CVE-2021-4140" title="CVE-2021-4140" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43531" id="CVE-2021-43531" title="CVE-2021-43531" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43532" id="CVE-2021-43532" title="CVE-2021-43532" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43533" id="CVE-2021-43533" title="CVE-2021-43533" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43534" id="CVE-2021-43534" title="CVE-2021-43534" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43535" id="CVE-2021-43535" title="CVE-2021-43535" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43536" id="CVE-2021-43536" title="CVE-2021-43536" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43537" id="CVE-2021-43537" title="CVE-2021-43537" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43538" id="CVE-2021-43538" title="CVE-2021-43538" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43539" id="CVE-2021-43539" title="CVE-2021-43539" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43540" id="CVE-2021-43540" title="CVE-2021-43540" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43541" id="CVE-2021-43541" title="CVE-2021-43541" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43542" id="CVE-2021-43542" title="CVE-2021-43542" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43543" id="CVE-2021-43543" title="CVE-2021-43543" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43545" id="CVE-2021-43545" title="CVE-2021-43545" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43546" id="CVE-2021-43546" title="CVE-2021-43546" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0511" id="CVE-2022-0511" title="CVE-2022-0511" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0843" id="CVE-2022-0843" title="CVE-2022-0843" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1097" id="CVE-2022-1097" title="CVE-2022-1097" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1196" id="CVE-2022-1196" title="CVE-2022-1196" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1529" id="CVE-2022-1529" title="CVE-2022-1529" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1802" id="CVE-2022-1802" title="CVE-2022-1802" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1919" id="CVE-2022-1919" title="CVE-2022-1919" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2200" id="CVE-2022-2200" title="CVE-2022-2200" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22737" id="CVE-2022-22737" title="CVE-2022-22737" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22738" id="CVE-2022-22738" title="CVE-2022-22738" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22739" id="CVE-2022-22739" title="CVE-2022-22739" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22740" id="CVE-2022-22740" title="CVE-2022-22740" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22741" id="CVE-2022-22741" title="CVE-2022-22741" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22742" id="CVE-2022-22742" title="CVE-2022-22742" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22743" id="CVE-2022-22743" title="CVE-2022-22743" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22745" id="CVE-2022-22745" title="CVE-2022-22745" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22747" id="CVE-2022-22747" title="CVE-2022-22747" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22748" id="CVE-2022-22748" title="CVE-2022-22748" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22753" id="CVE-2022-22753" title="CVE-2022-22753" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22754" id="CVE-2022-22754" title="CVE-2022-22754" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22755" id="CVE-2022-22755" title="CVE-2022-22755" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22756" id="CVE-2022-22756" title="CVE-2022-22756" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22757" id="CVE-2022-22757" title="CVE-2022-22757" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22759" id="CVE-2022-22759" title="CVE-2022-22759" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22760" id="CVE-2022-22760" title="CVE-2022-22760" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22761" id="CVE-2022-22761" title="CVE-2022-22761" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22763" id="CVE-2022-22763" title="CVE-2022-22763" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24713" id="CVE-2022-24713" title="CVE-2022-24713" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26381" id="CVE-2022-26381" title="CVE-2022-26381" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26382" id="CVE-2022-26382" title="CVE-2022-26382" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26383" id="CVE-2022-26383" title="CVE-2022-26383" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26384" id="CVE-2022-26384" title="CVE-2022-26384" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26385" id="CVE-2022-26385" title="CVE-2022-26385" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26386" id="CVE-2022-26386" title="CVE-2022-26386" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26387" id="CVE-2022-26387" title="CVE-2022-26387" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26485" id="CVE-2022-26485" title="CVE-2022-26485" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26486" id="CVE-2022-26486" title="CVE-2022-26486" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28281" id="CVE-2022-28281" title="CVE-2022-28281" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28282" id="CVE-2022-28282" title="CVE-2022-28282" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28283" id="CVE-2022-28283" title="CVE-2022-28283" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28284" id="CVE-2022-28284" title="CVE-2022-28284" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28285" id="CVE-2022-28285" title="CVE-2022-28285" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28286" id="CVE-2022-28286" title="CVE-2022-28286" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28287" id="CVE-2022-28287" title="CVE-2022-28287" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28289" id="CVE-2022-28289" title="CVE-2022-28289" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29909" id="CVE-2022-29909" title="CVE-2022-29909" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29911" id="CVE-2022-29911" title="CVE-2022-29911" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29912" id="CVE-2022-29912" title="CVE-2022-29912" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29914" id="CVE-2022-29914" title="CVE-2022-29914" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29915" id="CVE-2022-29915" title="CVE-2022-29915" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29916" id="CVE-2022-29916" title="CVE-2022-29916" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29918" id="CVE-2022-29918" title="CVE-2022-29918" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31736" id="CVE-2022-31736" title="CVE-2022-31736" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31737" id="CVE-2022-31737" title="CVE-2022-31737" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31738" id="CVE-2022-31738" title="CVE-2022-31738" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31740" id="CVE-2022-31740" title="CVE-2022-31740" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31741" id="CVE-2022-31741" title="CVE-2022-31741" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31742" id="CVE-2022-31742" title="CVE-2022-31742" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31743" id="CVE-2022-31743" title="CVE-2022-31743" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31744" id="CVE-2022-31744" title="CVE-2022-31744" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31745" id="CVE-2022-31745" title="CVE-2022-31745" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31748" id="CVE-2022-31748" title="CVE-2022-31748" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3266" id="CVE-2022-3266" title="CVE-2022-3266" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34468" id="CVE-2022-34468" title="CVE-2022-34468" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34469" id="CVE-2022-34469" title="CVE-2022-34469" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34470" id="CVE-2022-34470" title="CVE-2022-34470" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34471" id="CVE-2022-34471" title="CVE-2022-34471" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34472" id="CVE-2022-34472" title="CVE-2022-34472" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34473" id="CVE-2022-34473" title="CVE-2022-34473" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34474" id="CVE-2022-34474" title="CVE-2022-34474" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34475" id="CVE-2022-34475" title="CVE-2022-34475" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34476" id="CVE-2022-34476" title="CVE-2022-34476" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34477" id="CVE-2022-34477" title="CVE-2022-34477" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34479" id="CVE-2022-34479" title="CVE-2022-34479" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34480" id="CVE-2022-34480" title="CVE-2022-34480" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34481" id="CVE-2022-34481" title="CVE-2022-34481" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34482" id="CVE-2022-34482" title="CVE-2022-34482" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34483" id="CVE-2022-34483" title="CVE-2022-34483" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34484" id="CVE-2022-34484" title="CVE-2022-34484" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34485" id="CVE-2022-34485" title="CVE-2022-34485" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36318" id="CVE-2022-36318" title="CVE-2022-36318" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36319" id="CVE-2022-36319" title="CVE-2022-36319" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38472" id="CVE-2022-38472" title="CVE-2022-38472" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38473" id="CVE-2022-38473" title="CVE-2022-38473" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38477" id="CVE-2022-38477" title="CVE-2022-38477" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38478" id="CVE-2022-38478" title="CVE-2022-38478" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40956" id="CVE-2022-40956" title="CVE-2022-40956" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40957" id="CVE-2022-40957" title="CVE-2022-40957" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40958" id="CVE-2022-40958" title="CVE-2022-40958" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40959" id="CVE-2022-40959" title="CVE-2022-40959" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40960" id="CVE-2022-40960" title="CVE-2022-40960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40962" id="CVE-2022-40962" title="CVE-2022-40962" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42928" id="CVE-2022-42928" title="CVE-2022-42928" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43680" id="CVE-2022-43680" title="CVE-2022-43680" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45408" id="CVE-2022-45408" title="CVE-2022-45408" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45409" id="CVE-2022-45409" title="CVE-2022-45409" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45410" id="CVE-2022-45410" title="CVE-2022-45410" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45411" id="CVE-2022-45411" title="CVE-2022-45411" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45412" id="CVE-2022-45412" title="CVE-2022-45412" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45416" id="CVE-2022-45416" title="CVE-2022-45416" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45418" id="CVE-2022-45418" title="CVE-2022-45418" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45420" id="CVE-2022-45420" title="CVE-2022-45420" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45421" id="CVE-2022-45421" title="CVE-2022-45421" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46871" id="CVE-2022-46871" title="CVE-2022-46871" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46874" id="CVE-2022-46874" title="CVE-2022-46874" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46875" id="CVE-2022-46875" title="CVE-2022-46875" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46878" id="CVE-2022-46878" title="CVE-2022-46878" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46882" id="CVE-2022-46882" title="CVE-2022-46882" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0767" id="CVE-2023-0767" title="CVE-2023-0767" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1945" id="CVE-2023-1945" title="CVE-2023-1945" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1999" id="CVE-2023-1999" title="CVE-2023-1999" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23598" id="CVE-2023-23598" title="CVE-2023-23598" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23599" id="CVE-2023-23599" title="CVE-2023-23599" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23601" id="CVE-2023-23601" title="CVE-2023-23601" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23602" id="CVE-2023-23602" title="CVE-2023-23602" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23603" id="CVE-2023-23603" title="CVE-2023-23603" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25728" id="CVE-2023-25728" title="CVE-2023-25728" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25729" id="CVE-2023-25729" title="CVE-2023-25729" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25730" id="CVE-2023-25730" title="CVE-2023-25730" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25732" id="CVE-2023-25732" title="CVE-2023-25732" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25735" id="CVE-2023-25735" title="CVE-2023-25735" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25737" id="CVE-2023-25737" title="CVE-2023-25737" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25739" id="CVE-2023-25739" title="CVE-2023-25739" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25742" id="CVE-2023-25742" title="CVE-2023-25742" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25751" id="CVE-2023-25751" title="CVE-2023-25751" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25752" id="CVE-2023-25752" title="CVE-2023-25752" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28162" id="CVE-2023-28162" title="CVE-2023-28162" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28164" id="CVE-2023-28164" title="CVE-2023-28164" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28176" id="CVE-2023-28176" title="CVE-2023-28176" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29531" id="CVE-2023-29531" title="CVE-2023-29531" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29532" id="CVE-2023-29532" title="CVE-2023-29532" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29533" id="CVE-2023-29533" title="CVE-2023-29533" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29535" id="CVE-2023-29535" title="CVE-2023-29535" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29536" id="CVE-2023-29536" title="CVE-2023-29536" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29539" id="CVE-2023-29539" title="CVE-2023-29539" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29541" id="CVE-2023-29541" title="CVE-2023-29541" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29542" id="CVE-2023-29542" title="CVE-2023-29542" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29545" id="CVE-2023-29545" title="CVE-2023-29545" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29548" id="CVE-2023-29548" title="CVE-2023-29548" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29550" id="CVE-2023-29550" title="CVE-2023-29550" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32205" id="CVE-2023-32205" title="CVE-2023-32205" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32206" id="CVE-2023-32206" title="CVE-2023-32206" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32207" id="CVE-2023-32207" title="CVE-2023-32207" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32211" id="CVE-2023-32211" title="CVE-2023-32211" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32212" id="CVE-2023-32212" title="CVE-2023-32212" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32213" id="CVE-2023-32213" title="CVE-2023-32213" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32214" id="CVE-2023-32214" title="CVE-2023-32214" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32215" id="CVE-2023-32215" title="CVE-2023-32215" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34414" id="CVE-2023-34414" title="CVE-2023-34414" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34416" id="CVE-2023-34416" title="CVE-2023-34416" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37201" id="CVE-2023-37201" title="CVE-2023-37201" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37202" id="CVE-2023-37202" title="CVE-2023-37202" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37207" id="CVE-2023-37207" title="CVE-2023-37207" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37208" id="CVE-2023-37208" title="CVE-2023-37208" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37211" id="CVE-2023-37211" title="CVE-2023-37211" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4045" id="CVE-2023-4045" title="CVE-2023-4045" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4046" id="CVE-2023-4046" title="CVE-2023-4046" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4047" id="CVE-2023-4047" title="CVE-2023-4047" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4048" id="CVE-2023-4048" title="CVE-2023-4048" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4049" id="CVE-2023-4049" title="CVE-2023-4049" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4050" id="CVE-2023-4050" title="CVE-2023-4050" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4054" id="CVE-2023-4054" title="CVE-2023-4054" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4055" id="CVE-2023-4055" title="CVE-2023-4055" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4056" id="CVE-2023-4056" title="CVE-2023-4056" type="cve"/>
		</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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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's entry in a shared stub table, resulting in a potentially exploitable crash. This vulnerability affects Firefox &lt; 82.
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'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.
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.
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.
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.
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.
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.
CVE-2020-26951:A parsing and event loading mismatch in Firefox'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.
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.
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.
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.
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.
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.
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.
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.
CVE-2020-26965:Some websites have a feature &quot;Show Password&quot; 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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2020-26978:Using techniques that built on the slipstream research, a malicious webpage could have exposed both an internal network's hosts as well as services running on the user's local machine. This vulnerability affects Firefox &lt; 84, Thunderbird &lt; 78.6, and Firefox ESR &lt; 78.6.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2021-23961:Further techniques that built on the slipstream research combined with a malicious webpage could have exposed both an internal network's hosts as well as services running on the user's local machine. This vulnerability affects Firefox &lt; 85.
CVE-2021-23962:Incorrect use of the '&lt;RowCountChanged&gt;' method could have led to a user-after-poison and a potentially exploitable crash. This vulnerability affects Firefox &lt; 85.
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.
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.
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.
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.
CVE-2021-23969:As specified in the W3C Content Security Policy draft, when creating a violation report, &quot;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.&quot; 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's origin. This vulnerability affects Firefox &lt; 86, Thunderbird &lt; 78.8, and Firefox ESR &lt; 78.8.
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.
CVE-2021-23971:When processing a redirect with a conflicting Referrer-Policy, Firefox would have adopted the redirect'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.
CVE-2021-23972:One phishing tactic on the web is to provide a link with HTTP Auth. For example 'https://www.phishingtarget.com@evil.com'. 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.
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.
CVE-2021-23974:The DOMParser API did not properly process '&lt;noscript&gt;' elements for escaping. This could be used as an mXSS vector to bypass an HTML Sanitizer. This vulnerability affects Firefox &lt; 86.
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.
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.
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.
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.
CVE-2021-23982:Using techniques that built on the slipstream research, a malicious webpage could have scanned both an internal network's hosts as well as services running on the user's local machine utilizing WebRTC connections. This vulnerability affects Firefox ESR &lt; 78.9, Firefox &lt; 87, and Thunderbird &lt; 78.9.
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.
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.
CVE-2021-23985:If an attacker is able to alter specific about:config values (for example malware running on the user'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'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.
CVE-2021-23986:A malicious extension with the 'search' 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.
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.
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.
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.
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.
CVE-2021-23996:By utilizing 3D CSS in conjunction with Javascript, content could have been rendered outside the webpage'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.
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.
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.
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.
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=&quot;file&quot;&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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2021-38504:When interacting with an HTML input element'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.
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'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.
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.
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.
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.
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's choosing. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.
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'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.
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.
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.
CVE-2021-43532:The 'Copy Image Link' 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2021-43543:Documents loaded with the CSP sandbox directive could have escaped the sandbox'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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'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.
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's document that e.g. had a JavaScript event handler - the event handler would have run despite the iframe's sandbox. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.
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.
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's Content Security Policy. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.
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.
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's considered part of the crate'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'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.
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.
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.
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.
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.
CVE-2022-26385:In unusual circumstances, an individual thread may outlive the thread's manager during shutdown. This could have led to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox &lt; 98.
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.
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.
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.
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.
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.
CVE-2022-28282:By using a link with &lt;code&gt;rel=&quot;localization&quot;&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.
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.
CVE-2022-28284:SVG'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's implementation was aligned with theirs. This vulnerability affects Firefox &lt; 99.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2022-31743:Firefox'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.
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's Content Security Policy. This vulnerability affects Firefox ESR &lt; 91.11, Thunderbird &lt; 102, Thunderbird &lt; 91.11, and Firefox &lt; 101.
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.
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.
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.
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.
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.
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.
CVE-2022-34471:When downloading an update for an addon, the downloaded addon update'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2022-38473:A cross-origin iframe referencing an XSLT document would inherit the parent domain'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.
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.
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.
CVE-2022-40956:When injecting an HTML base element, some requests would ignore the CSP's base-uri settings and accept the injected element's base instead. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2022-45416:Keyboard events reference strings like &quot;KeyA&quot; 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.
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.
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.
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.
CVE-2022-46871:An out of date library (libusrsctp) contained vulnerabilities that could potentially be exploited. This vulnerability affects Firefox &lt; 108.
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.
CVE-2022-46875:The executable file warning was not presented when downloading .atloc and .ftploc files, which can run commands on a user'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.
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.
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.
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.
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.
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.
CVE-2023-23598:Due to the Firefox GTK wrapper code'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.
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.
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.
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.
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'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.
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'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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
*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.
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.
*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.
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.
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.
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.
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.
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.
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.
*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.
CVE-2023-29545:Similar to CVE-2023-28163, this time when choosing 'Save Link As', suggested filenames containing environment variable names would have resolved those in the context of the current user. 
*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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2023-32214:Protocol handlers `ms-cxh` and `ms-cxh-full` could have been leveraged to trigger a denial of service.
*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.
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.
CVE-2023-34414:The error page for sites with invalid TLS certificates was missing the
activation-delay Firefox uses to protect prompts and permission dialogs
from attacks that exploit human response time delays. If a malicious
page elicited user clicks in precise locations immediately before
navigating to a site with a certificate error and made the renderer
extremely busy at the same time, it could create a gap between when
the error page was loaded and when the display actually refreshed.
With the right timing the elicited clicks could land in that gap and 
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2023-4054:When opening appref-ms files, Firefox did not warn the user that these files may contain malicious code. 
*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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39350" id="CVE-2023-39350" title="CVE-2023-39350" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39351" id="CVE-2023-39351" title="CVE-2023-39351" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39352" id="CVE-2023-39352" title="CVE-2023-39352" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39353" id="CVE-2023-39353" title="CVE-2023-39353" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39354" id="CVE-2023-39354" title="CVE-2023-39354" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39356" id="CVE-2023-39356" title="CVE-2023-39356" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40181" id="CVE-2023-40181" title="CVE-2023-40181" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40186" id="CVE-2023-40186" title="CVE-2023-40186" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40188" id="CVE-2023-40188" title="CVE-2023-40188" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40567" id="CVE-2023-40567" title="CVE-2023-40567" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40569" id="CVE-2023-40569" title="CVE-2023-40569" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40589" id="CVE-2023-40589" title="CVE-2023-40589" type="cve"/>
		</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.
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.
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.
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.
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.
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.
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'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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36664" id="CVE-2023-36664" title="CVE-2023-36664" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39742" id="CVE-2023-39742" title="CVE-2023-39742" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29409" id="CVE-2023-29409" title="CVE-2023-29409" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37329" id="CVE-2023-37329" title="CVE-2023-37329" type="cve"/>
		</references>
		<description>CVE-2023-37329:Heap overwrite in PGS subtitle overlay decoder.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37327" id="CVE-2023-37327" title="CVE-2023-37327" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37328" id="CVE-2023-37328" title="CVE-2023-37328" type="cve"/>
		</references>
		<description>CVE-2023-37327:Integer overflow leading to heap overwrite in FLAC image tag handling.
CVE-2023-37328:Heap overwrite in subtitle parsing.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37327" id="CVE-2023-37327" title="CVE-2023-37327" type="cve"/>
		</references>
		<description>CVE-2023-37327:Integer overflow leading to heap overwrite in FLAC image tag handling.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21549" id="CVE-2022-21549" title="CVE-2022-21549" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21830" id="CVE-2023-21830" title="CVE-2023-21830" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21937" id="CVE-2023-21937" title="CVE-2023-21937" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22049" id="CVE-2023-22049" title="CVE-2023-22049" type="cve"/>
		</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.
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.
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).
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).
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).
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).
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).
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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21835" id="CVE-2023-21835" title="CVE-2023-21835" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21937" id="CVE-2023-21937" title="CVE-2023-21937" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22006" id="CVE-2023-22006" title="CVE-2023-22006" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22036" id="CVE-2023-22036" title="CVE-2023-22036" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22041" id="CVE-2023-22041" title="CVE-2023-22041" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22049" id="CVE-2023-22049" title="CVE-2023-22049" type="cve"/>
		</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.
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).
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).
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.
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.
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).
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.
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.
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.
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.
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).
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.
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).
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45685" id="CVE-2022-45685" title="CVE-2022-45685" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1436" id="CVE-2023-1436" title="CVE-2023-1436" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1206" id="CVE-2023-1206" title="CVE-2023-1206" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20593" id="CVE-2023-20593" title="CVE-2023-20593" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34319" id="CVE-2023-34319" title="CVE-2023-34319" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38432" id="CVE-2023-38432" title="CVE-2023-38432" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40283" id="CVE-2023-40283" title="CVE-2023-40283" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4194" id="CVE-2023-4194" title="CVE-2023-4194" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32250" id="CVE-2023-32250" title="CVE-2023-32250" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32252" id="CVE-2023-32252" title="CVE-2023-32252" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32257" id="CVE-2023-32257" title="CVE-2023-32257" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3865" id="CVE-2023-3865" title="CVE-2023-3865" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4273" id="CVE-2023-4273" title="CVE-2023-4273" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32247" id="CVE-2023-32247" title="CVE-2023-32247" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32249" id="CVE-2023-32249" title="CVE-2023-32249" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32251" id="CVE-2023-32251" title="CVE-2023-32251" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32253" id="CVE-2023-32253" title="CVE-2023-32253" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3777" id="CVE-2023-3777" title="CVE-2023-3777" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3866" id="CVE-2023-3866" title="CVE-2023-3866" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4015" id="CVE-2023-4015" title="CVE-2023-4015" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4622" id="CVE-2023-4622" title="CVE-2023-4622" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4623" id="CVE-2023-4623" title="CVE-2023-4623" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45884" id="CVE-2022-45884" title="CVE-2022-45884" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45887" id="CVE-2022-45887" title="CVE-2022-45887" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2156" id="CVE-2023-2156" title="CVE-2023-2156" type="cve"/>
		</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%.
CVE-2023-20593:An issue in “Zen 2” CPUs, under specific microarchitectural circumstances, may allow an attacker to potentially access sensitive information.
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.
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.
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.
CVE-2023-4194:A flaw was found in the Linux kernel'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 (&quot;tun: tun_chr_open(): correctly initialize socket uid&quot;), - 66b2c338adce (&quot;tap: tap_open(): correctly initialize socket uid&quot;), pass &quot;inode-&gt;i_uid&quot; to sock_init_data_uid() as the last parameter and that turns out to not be accurate.
CVE-2023-32250:A flaw was found in the Linux kernel'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.
CVE-2023-32252:A flaw was found in the Linux kernel'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.
CVE-2023-32257:A flaw was found in the Linux kernel'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.
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.
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.
CVE-2023-32247:A flaw was found in the Linux kernel'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.
CVE-2023-32249:Linux Kernel ksmbd Multichannel Improper Authentication Session Hijack Vulnerability.
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.
CVE-2023-32253:Linux Kernel ksmbd Session Deadlock Denial-of-Service Vulnerability
CVE-2023-3777:A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
When nf_tables_delrule() is flushing table rules, it is not checked whether the chain is bound and the chain's owner rule can also release the objects in certain circumstances.
We recommend upgrading past commit 6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8.
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.
CVE-2023-4015:A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
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.
CVE-2023-4622:A use-after-free vulnerability in the Linux kernel's af_unix component can be exploited to achieve local privilege escalation.
The unix_stream_sendpage() function tries to add data to the last skb in the peer'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.
CVE-2023-4623:A use-after-free vulnerability in the Linux kernel's net/sched: sch_hfsc (HFSC qdisc traffic control) component can be exploited to achieve local privilege escalation.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21469" id="CVE-2020-21469" title="CVE-2020-21469" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2454" id="CVE-2023-2454" title="CVE-2023-2454" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2455" id="CVE-2023-2455" title="CVE-2023-2455" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39417" id="CVE-2023-39417" title="CVE-2023-39417" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39418" id="CVE-2023-39418" title="CVE-2023-39418" type="cve"/>
		</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).
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.
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.
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, '', or &quot;&quot;). 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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38710" id="CVE-2023-38710" title="CVE-2023-38710" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38711" id="CVE-2023-38711" title="CVE-2023-38711" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38712" id="CVE-2023-38712" title="CVE-2023-38712" type="cve"/>
		</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'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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34526" id="CVE-2022-34526" title="CVE-2022-34526" type="cve"/>
		</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 &quot;tiffsplit&quot; or &quot;tiffcrop&quot; utilities.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36328" id="CVE-2023-36328" title="CVE-2023-36328" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33196" id="CVE-2022-33196" title="CVE-2022-33196" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38090" id="CVE-2022-38090" title="CVE-2022-38090" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40982" id="CVE-2022-40982" title="CVE-2022-40982" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21528" id="CVE-2020-21528" title="CVE-2020-21528" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41881" id="CVE-2022-41881" title="CVE-2022-41881" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25881" id="CVE-2022-25881" title="CVE-2022-25881" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32212" id="CVE-2022-32212" title="CVE-2022-32212" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32213" id="CVE-2022-32213" title="CVE-2022-32213" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32214" id="CVE-2022-32214" title="CVE-2022-32214" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32215" id="CVE-2022-32215" title="CVE-2022-32215" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35256" id="CVE-2022-35256" title="CVE-2022-35256" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23918" id="CVE-2023-23918" title="CVE-2023-23918" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23920" id="CVE-2023-23920" title="CVE-2023-23920" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30581" id="CVE-2023-30581" title="CVE-2023-30581" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30589" id="CVE-2023-30589" title="CVE-2023-30589" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30590" id="CVE-2023-30590" title="CVE-2023-30590" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32002" id="CVE-2023-32002" title="CVE-2023-32002" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32006" id="CVE-2023-32006" title="CVE-2023-32006" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32559" id="CVE-2023-32559" title="CVE-2023-32559" type="cve"/>
		</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.
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.
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).
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).
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).
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.
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.
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.
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.
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).
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
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.
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.
This vulnerability affects all users using the experimental policy mechanism in all active release lines: 16.x, 18.x and, 20.x.
Please note that at the time this CVE was issued, the policy is an experimental feature of Node.js.
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.
This vulnerability affects all users using the experimental policy mechanism in all active release lines: 16.x, 18.x, and, 20.x.
Please note that at the time this CVE was issued, the policy is an experimental feature of Node.js.
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('spawn_sync')` 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20867" id="CVE-2023-20867" title="CVE-2023-20867" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20900" id="CVE-2023-20900" title="CVE-2023-20900" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31631" id="CVE-2022-31631" title="CVE-2022-31631" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0567" id="CVE-2023-0567" title="CVE-2023-0567" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0568" id="CVE-2023-0568" title="CVE-2023-0568" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0662" id="CVE-2023-0662" title="CVE-2023-0662" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3823" id="CVE-2023-3823" title="CVE-2023-3823" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3824" id="CVE-2023-3824" title="CVE-2023-3824" type="cve"/>
		</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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-23804" id="CVE-2020-23804" title="CVE-2020-23804" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37050" id="CVE-2022-37050" title="CVE-2022-37050" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37051" id="CVE-2022-37051" title="CVE-2022-37051" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37052" id="CVE-2022-37052" title="CVE-2022-37052" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38349" id="CVE-2022-38349" title="CVE-2022-38349" type="cve"/>
		</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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2625" id="CVE-2022-2625" title="CVE-2022-2625" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2454" id="CVE-2023-2454" title="CVE-2023-2454" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2455" id="CVE-2023-2455" title="CVE-2023-2455" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39417" id="CVE-2023-39417" title="CVE-2023-39417" type="cve"/>
		</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.
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.
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.
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, '', or &quot;&quot;). 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-5237" id="CVE-2015-5237" title="CVE-2015-5237" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-22570" id="CVE-2021-22570" title="CVE-2021-22570" type="cve"/>
		</references>
		<description>CVE-2015-5237:protobuf allows remote authenticated attackers to cause a heap-based buffer overflow.
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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45198" id="CVE-2022-45198" title="CVE-2022-45198" type="cve"/>
		</references>
		<description>CVE-2022-45198:Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40217" id="CVE-2023-40217" title="CVE-2023-40217" type="cve"/>
		</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 &quot;not connected&quot; and won'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36648" id="CVE-2022-36648" title="CVE-2022-36648" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32763" id="CVE-2023-32763" title="CVE-2023-32763" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37369" id="CVE-2023-37369" title="CVE-2023-37369" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32762" id="CVE-2023-32762" title="CVE-2023-32762" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37369" id="CVE-2023-37369" title="CVE-2023-37369" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33285" id="CVE-2023-33285" title="CVE-2023-33285" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34410" id="CVE-2023-34410" title="CVE-2023-34410" type="cve"/>
		</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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35977" id="CVE-2022-35977" title="CVE-2022-35977" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3647" id="CVE-2022-3647" title="CVE-2022-3647" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22458" id="CVE-2023-22458" title="CVE-2023-22458" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25155" id="CVE-2023-25155" title="CVE-2023-25155" type="cve"/>
		</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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38037" id="CVE-2023-38037" title="CVE-2023-38037" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38037" id="CVE-2023-38037" title="CVE-2023-38037" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41080" id="CVE-2023-41080" title="CVE-2023-41080" type="cve"/>
		</references>
		<description>CVE-2023-41080:URL Redirection to Untrusted Site ('Open Redirect') 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.
The vulnerability is limited to the ROOT (default) web application.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4733" id="CVE-2023-4733" title="CVE-2023-4733" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4734" id="CVE-2023-4734" title="CVE-2023-4734" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4735" id="CVE-2023-4735" title="CVE-2023-4735" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4736" id="CVE-2023-4736" title="CVE-2023-4736" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4738" id="CVE-2023-4738" title="CVE-2023-4738" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4750" id="CVE-2023-4750" title="CVE-2023-4750" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4752" id="CVE-2023-4752" title="CVE-2023-4752" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4781" id="CVE-2023-4781" title="CVE-2023-4781" type="cve"/>
		</references>
		<description>CVE-2023-4733:Use After Free in GitHub repository vim/vim prior to 9.0.1840.
CVE-2023-4734:Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1846.
CVE-2023-4735:Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.1847.
CVE-2023-4736:Untrusted Search Path in GitHub repository vim/vim prior to 9.0.1833.
CVE-2023-4738:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1848.
CVE-2023-4750:Use After Free in GitHub repository vim/vim prior to 9.0.1857.
CVE-2023-4752:Use After Free in GitHub repository vim/vim prior to 9.0.1858.
CVE-2023-4781:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1873.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2906" id="CVE-2023-2906" title="CVE-2023-2906" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3649" id="CVE-2023-3649" title="CVE-2023-3649" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4511" id="CVE-2023-4511" title="CVE-2023-4511" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4513" id="CVE-2023-4513" title="CVE-2023-4513" type="cve"/>
		</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.
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
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
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-09-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40152" id="CVE-2022-40152" title="CVE-2022-40152" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5341" id="CVE-2023-5341" title="CVE-2023-5341" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38469" id="CVE-2023-38469" title="CVE-2023-38469" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38470" id="CVE-2023-38470" title="CVE-2023-38470" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38471" id="CVE-2023-38471" title="CVE-2023-38471" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38472" id="CVE-2023-38472" title="CVE-2023-38472" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38473" id="CVE-2023-38473" title="CVE-2023-38473" type="cve"/>
		</references>
		<description>CVE-2023-38469:A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.
CVE-2023-38470:A vulnerability was found in Avahi. A reachable assertion exists in the avahi_escape_label() function.
CVE-2023-38471:A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.
CVE-2023-38472:A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.
CVE-2023-38473:A vulnerability was found in Avahi. A reachable assertion exists in the avahi_alternative_host_name() function.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38398" id="CVE-2022-38398" title="CVE-2022-38398" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38648" id="CVE-2022-38648" title="CVE-2022-38648" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40146" id="CVE-2022-40146" title="CVE-2022-40146" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44729" id="CVE-2022-44729" title="CVE-2022-44729" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44730" id="CVE-2022-44730" title="CVE-2022-44730" type="cve"/>
		</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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3341" id="CVE-2023-3341" title="CVE-2023-3341" type="cve"/>
		</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's configured TCP port is necessary.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38533" id="CVE-2022-38533" title="CVE-2022-38533" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3854" id="CVE-2022-3854" title="CVE-2022-3854" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43040" id="CVE-2023-43040" title="CVE-2023-43040" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4504" id="CVE-2023-4504" title="CVE-2023-4504" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38545" id="CVE-2023-38545" title="CVE-2023-38545" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38546" id="CVE-2023-38546" title="CVE-2023-38546" type="cve"/>
		</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.
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 &quot;let the host resolve the name&quot; 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.
CVE-2023-38546:This flaw allows an attacker to insert cookies at will into a running program
using libcurl, if the specific series of conditions are met.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48337" id="CVE-2022-48337" title="CVE-2022-48337" type="cve"/>
		</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 &quot;etags -u *&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4573" id="CVE-2023-4573" title="CVE-2023-4573" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4574" id="CVE-2023-4574" title="CVE-2023-4574" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4575" id="CVE-2023-4575" title="CVE-2023-4575" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4576" id="CVE-2023-4576" title="CVE-2023-4576" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4581" id="CVE-2023-4581" title="CVE-2023-4581" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4584" id="CVE-2023-4584" title="CVE-2023-4584" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4863" id="CVE-2023-4863" title="CVE-2023-4863" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5217" id="CVE-2023-5217" title="CVE-2023-5217" type="cve"/>
		</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.
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.
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.
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.
CVE-2023-4581:Excel `.xll` add-in files did not have a blocklist entry in Firefox'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.
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.
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)
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4039" id="CVE-2023-4039" title="CVE-2023-4039" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39129" id="CVE-2023-39129" title="CVE-2023-39129" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39742" id="CVE-2023-39742" title="CVE-2023-39742" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4806" id="CVE-2023-4806" title="CVE-2023-4806" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4813" id="CVE-2023-4813" title="CVE-2023-4813" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4911" id="CVE-2023-4911" title="CVE-2023-4911" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5156" id="CVE-2023-5156" title="CVE-2023-5156" type="cve"/>
		</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.
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.
CVE-2023-4911:A buffer overflow was discovered in the GNU C Library'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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33953" id="CVE-2023-33953" title="CVE-2023-33953" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4785" id="CVE-2023-4785" title="CVE-2023-4785" type="cve"/>
		</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:
CVE-2023-4785:Lack of error handling in the TCP server in Google'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4692" id="CVE-2023-4692" title="CVE-2023-4692" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4693" id="CVE-2023-4693" title="CVE-2023-4693" type="cve"/>
		</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.
CVE-2023-4693:An out-of-bounds read flaw was found on grub2'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40474" id="CVE-2023-40474" title="CVE-2023-40474" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40475" id="CVE-2023-40475" title="CVE-2023-40475" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40476" id="CVE-2023-40476" title="CVE-2023-40476" type="cve"/>
		</references>
		<description>CVE-2023-40474:gstreamer-plugins-bad: GStreamer MXF File Parsing Integer Overflow Remote Code Execution Vulnerability
CVE-2023-40475:gstreamer-plugins-bad: GStreamer MXF File Parsing Integer Overflow Remote Code Execution Vulnerability
CVE-2023-40476:gstreamer-plugins-bad: GStreamer H265 Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31122" id="CVE-2023-31122" title="CVE-2023-31122" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45802" id="CVE-2023-45802" title="CVE-2023-45802" type="cve"/>
		</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.
CVE-2023-45802:When a HTTP/2 stream was reset (RST frame) by a client, there was a time window were the request'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 &quot;normal&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21549" id="CVE-2022-21549" title="CVE-2022-21549" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21830" id="CVE-2023-21830" title="CVE-2023-21830" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21835" id="CVE-2023-21835" title="CVE-2023-21835" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2193" id="CVE-2023-2193" title="CVE-2023-2193" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22006" id="CVE-2023-22006" title="CVE-2023-22006" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22025" id="CVE-2023-22025" title="CVE-2023-22025" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22036" id="CVE-2023-22036" title="CVE-2023-22036" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22041" id="CVE-2023-22041" title="CVE-2023-22041" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22043" id="CVE-2023-22043" title="CVE-2023-22043" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22044" id="CVE-2023-22044" title="CVE-2023-22044" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22049" id="CVE-2023-22049" title="CVE-2023-22049" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"/>
		</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).
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.
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).
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).
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).
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.
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40982" id="CVE-2022-40982" title="CVE-2022-40982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4379" id="CVE-2022-4379" title="CVE-2022-4379" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45887" id="CVE-2022-45887" title="CVE-2022-45887" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45919" id="CVE-2022-45919" title="CVE-2022-45919" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20588" id="CVE-2023-20588" title="CVE-2023-20588" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21400" id="CVE-2023-21400" title="CVE-2023-21400" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4881" id="CVE-2023-4881" title="CVE-2023-4881" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4921" id="CVE-2023-4921" title="CVE-2023-4921" type="cve"/>
		</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.
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
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.
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.
CVE-2023-20588:A division-by-zero error on some AMD processors can potentially return speculative data resulting in loss of confidentiality.
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.
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.
CVE-2023-4921:A use-after-free vulnerability in the Linux kernel'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33634" id="CVE-2021-33634" title="CVE-2021-33634" type="cve"/>
		</references>
		<description>CVE-2021-33634:Isula uses the lxc runtime (default) to run malicious images, which can cause DOS.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43785" id="CVE-2023-43785" title="CVE-2023-43785" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43786" id="CVE-2023-43786" title="CVE-2023-43786" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43787" id="CVE-2023-43787" title="CVE-2023-43787" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43786" id="CVE-2023-43786" title="CVE-2023-43786" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43787" id="CVE-2023-43787" title="CVE-2023-43787" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43788" id="CVE-2023-43788" title="CVE-2023-43788" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43789" id="CVE-2023-43789" title="CVE-2023-43789" type="cve"/>
		</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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33065" id="CVE-2022-33065" title="CVE-2022-33065" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44488" id="CVE-2023-44488" title="CVE-2023-44488" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5217" id="CVE-2023-5217" title="CVE-2023-5217" type="cve"/>
		</references>
		<description>CVE-2023-44488:VP9 in libvpx before 1.13.1 mishandles widths, leading to a crash related to encoding.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4863" id="CVE-2023-4863" title="CVE-2023-4863" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5129" id="CVE-2023-5129" title="CVE-2023-5129" type="cve"/>
		</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)
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45322" id="CVE-2023-45322" title="CVE-2023-45322" type="cve"/>
		</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's position is &quot;I don't think these issues are critical enough to warrant a CVE ID ... because an attacker typically can't control when memory allocations fail.&quot;</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23583" id="CVE-2023-23583" title="CVE-2023-23583" type="cve"/>
		</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>FusionOS</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4874" id="CVE-2023-4874" title="CVE-2023-4874" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4875" id="CVE-2023-4875" title="CVE-2023-4875" type="cve"/>
		</references>
		<description>CVE-2023-4874:Null pointer dereference when viewing a specially crafted email in Mutt &gt;1.5.2 &lt;2.2.12
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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23918" id="CVE-2023-23918" title="CVE-2023-23918" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34058" id="CVE-2023-34058" title="CVE-2023-34058" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34059" id="CVE-2023-34059" title="CVE-2023-34059" type="cve"/>
		</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 .
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 
/dev/uinput file descriptor allowing them to simulate user inputs.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"/>
		</references>
		<description>CVE-2023-3446:Checking excessively long DH keys or parameters may be very slow.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45853" id="CVE-2023-45853" title="CVE-2023-45853" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2977" id="CVE-2023-2977" title="CVE-2023-2977" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5366" id="CVE-2023-5366" title="CVE-2023-5366" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41915" id="CVE-2023-41915" title="CVE-2023-41915" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41419" id="CVE-2023-41419" title="CVE-2023-41419" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44271" id="CVE-2023-44271" title="CVE-2023-44271" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43804" id="CVE-2023-43804" title="CVE-2023-43804" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45803" id="CVE-2023-45803" title="CVE-2023-45803" type="cve"/>
		</references>
		<description>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.
CVE-2023-45803:urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn'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't putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn'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'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>FusionOS</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24329" id="CVE-2023-24329" title="CVE-2023-24329" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40217" id="CVE-2023-40217" title="CVE-2023-40217" type="cve"/>
		</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.
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 &quot;not connected&quot; and won'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3255" id="CVE-2023-3255" title="CVE-2023-3255" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3255" id="CVE-2023-3255" title="CVE-2023-3255" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33285" id="CVE-2023-33285" title="CVE-2023-33285" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34410" id="CVE-2023-34410" title="CVE-2023-34410" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45145" id="CVE-2023-45145" title="CVE-2023-45145" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3961" id="CVE-2023-3961" title="CVE-2023-3961" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4091" id="CVE-2023-4091" title="CVE-2023-4091" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4154" id="CVE-2023-4154" title="CVE-2023-4154" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42669" id="CVE-2023-42669" title="CVE-2023-42669" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42670" id="CVE-2023-42670" title="CVE-2023-42670" type="cve"/>
		</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.
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 &quot;acl_xattr&quot; is configured with &quot;acl_xattr:ignore system acls = yes&quot;. 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's permissions.
CVE-2023-4154:A design flaw was found in Samba'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.
CVE-2023-42669:A vulnerability was found in Samba's &quot;rpcecho&quot; development server, a non-Windows RPC server used to test Samba's DCE/RPC stack elements. This vulnerability stems from an RPC function that can be blocked indefinitely. The issue arises because the &quot;rpcecho&quot; service operates with only one worker in the main RPC task, allowing calls to the &quot;rpcecho&quot; server to be blocked for a specified time, causing service disruptions. This disruption is triggered by a &quot;sleep()&quot; call in the &quot;dcesrv_echo_TestSleep()&quot; function under specific conditions. Authenticated users or attackers can exploit this vulnerability to make calls to the &quot;rpcecho&quot; 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 &quot;rpcecho&quot; runs in the main RPC task.
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's RPC server experiences a high load or unresponsiveness, servers intended for non-AD DC purposes (for example, NT4-emulation &quot;classic DCs&quot;) 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 &quot;The procedure number is out of range&quot; when using tools like Active Directory Users. This flaw allows an attacker to disrupt AD DC services.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40546" id="CVE-2023-40546" title="CVE-2023-40546" type="cve"/>
		</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' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43642" id="CVE-2023-43642" title="CVE-2023-43642" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32697" id="CVE-2023-32697" title="CVE-2023-32697" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46724" id="CVE-2023-46724" title="CVE-2023-46724" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46728" id="CVE-2023-46728" title="CVE-2023-46728" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46846" id="CVE-2023-46846" title="CVE-2023-46846" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46847" id="CVE-2023-46847" title="CVE-2023-46847" type="cve"/>
		</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's patch archives. Those who you use a prepackaged version of Squid should refer to the package vendor for availability information on updated packages.
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'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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45648" id="CVE-2023-45648" title="CVE-2023-45648" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46316" id="CVE-2023-46316" title="CVE-2023-46316" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46246" id="CVE-2023-46246" title="CVE-2023-46246" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5344" id="CVE-2023-5344" title="CVE-2023-5344" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5441" id="CVE-2023-5441" title="CVE-2023-5441" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5535" id="CVE-2023-5535" title="CVE-2023-5535" type="cve"/>
		</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'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.
CVE-2023-5344:Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1969.
CVE-2023-5441:NULL Pointer Dereference in GitHub repository vim/vim prior to 20d161ace307e28690229b68584f2d84556f8960.
CVE-2023-5535:Use After Free in GitHub repository vim/vim prior to v9.0.2010.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5371" id="CVE-2023-5371" title="CVE-2023-5371" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5367" id="CVE-2023-5367" title="CVE-2023-5367" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5380" id="CVE-2023-5380" title="CVE-2023-5380" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5574" id="CVE-2023-5574" title="CVE-2023-5574" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5574" id="CVE-2023-5574" title="CVE-2023-5574" type="cve"/>
		</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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45853" id="CVE-2023-45853" title="CVE-2023-45853" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-11-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44981" id="CVE-2023-44981" title="CVE-2023-44981" type="cve"/>
		</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's missing, like 'eve@EXAMPLE.COM', 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>FusionOS</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-37533" id="CVE-2021-37533" title="CVE-2021-37533" type="cve"/>
		</references>
		<description>CVE-2021-37533:Prior to Apache Commons Net 3.9.0, Net'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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46218" id="CVE-2023-46218" title="CVE-2023-46218" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46219" id="CVE-2023-46219" title="CVE-2023-46219" type="cve"/>
		</references>
		<description>CVE-2023-46218:This flaw allows a malicious HTTP server to set &quot;super cookies&quot; 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'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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39130" id="CVE-2023-39130" title="CVE-2023-39130" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46751" id="CVE-2023-46751" title="CVE-2023-46751" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48161" id="CVE-2023-48161" title="CVE-2023-48161" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5981" id="CVE-2023-5981" title="CVE-2023-5981" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0836" id="CVE-2023-0836" title="CVE-2023-0836" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45539" id="CVE-2023-45539" title="CVE-2023-45539" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41853" id="CVE-2022-41853" title="CVE-2022-41853" type="cve"/>
		</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 &quot;hsqldb.method_class_names&quot; to classes which are allowed to be called. For example, System.setProperty(&quot;hsqldb.method_class_names&quot;, &quot;abc&quot;) or Java argument -Dhsqldb.method_class_names=&quot;abc&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22067" id="CVE-2023-22067" title="CVE-2023-22067" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"/>
		</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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22025" id="CVE-2023-22025" title="CVE-2023-22025" type="cve"/>
		</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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40149" id="CVE-2022-40149" title="CVE-2022-40149" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40150" id="CVE-2022-40150" title="CVE-2022-40150" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45685" id="CVE-2022-45685" title="CVE-2022-45685" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45693" id="CVE-2022-45693" title="CVE-2022-45693" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1436" id="CVE-2023-1436" title="CVE-2023-1436" type="cve"/>
		</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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42755" id="CVE-2023-42755" title="CVE-2023-42755" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5197" id="CVE-2023-5197" title="CVE-2023-5197" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1193" id="CVE-2023-1193" title="CVE-2023-1193" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25775" id="CVE-2023-25775" title="CVE-2023-25775" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47233" id="CVE-2023-47233" title="CVE-2023-47233" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6176" id="CVE-2023-6176" title="CVE-2023-6176" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39197" id="CVE-2023-39197" title="CVE-2023-39197" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5197" id="CVE-2023-5197" title="CVE-2023-5197" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42753" id="CVE-2023-42753" title="CVE-2023-42753" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39194" id="CVE-2023-39194" title="CVE-2023-39194" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45871" id="CVE-2023-45871" title="CVE-2023-45871" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42754" id="CVE-2023-42754" title="CVE-2023-42754" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39192" id="CVE-2023-39192" title="CVE-2023-39192" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39193" id="CVE-2023-39193" title="CVE-2023-39193" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39189" id="CVE-2023-39189" title="CVE-2023-39189" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31085" id="CVE-2023-31085" title="CVE-2023-31085" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5717" id="CVE-2023-5717" title="CVE-2023-5717" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45862" id="CVE-2023-45862" title="CVE-2023-45862" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45919" id="CVE-2022-45919" title="CVE-2022-45919" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31083" id="CVE-2023-31083" title="CVE-2023-31083" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2593" id="CVE-2023-2593" title="CVE-2023-2593" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32256" id="CVE-2023-32256" title="CVE-2023-32256" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32258" id="CVE-2023-32258" title="CVE-2023-32258" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32246" id="CVE-2023-32246" title="CVE-2023-32246" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32254" id="CVE-2023-32254" title="CVE-2023-32254" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44033" id="CVE-2022-44033" title="CVE-2022-44033" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34324" id="CVE-2023-34324" title="CVE-2023-34324" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2898" id="CVE-2023-2898" title="CVE-2023-2898" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46862" id="CVE-2023-46862" title="CVE-2023-46862" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37453" id="CVE-2023-37453" title="CVE-2023-37453" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5178" id="CVE-2023-5178" title="CVE-2023-5178" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46813" id="CVE-2023-46813" title="CVE-2023-46813" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45884" id="CVE-2022-45884" title="CVE-2022-45884" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39198" id="CVE-2023-39198" title="CVE-2023-39198" type="cve"/>
		</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.
CVE-2023-5197:A use-after-free vulnerability in the Linux kernel'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.
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.
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.
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 &quot;could be exploited in a real world scenario.&quot; This is related to brcmf_cfg80211_escan_timeout_worker in drivers/net/wireless/broadcom/brcm80211/brcmfmac/cfg80211.c.
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.
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.
CVE-2023-5197:A use-after-free vulnerability in the Linux kernel'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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2023-5717:A heap out-of-bounds write vulnerability in the Linux kernel's Linux Kernel Performance Events (perf) component can be exploited to achieve local privilege escalation. If perf_read_group() is called while an event's sibling_list is smaller than its child's sibling_list, it can increment or write to memory locations outside of the allocated buffer.
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.
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.
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.
CVE-2023-2593:VUL-0: CVE-2023-2593: kernel: Linux Kernel ksmbd Memory Exhaustion Denial-of-Service Vulnerability
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.
CVE-2023-32258:A flaw was found in the Linux kernel'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.
CVE-2023-32246:VUL-0: CVE-2023-32246: kernel: Linux Kernel ksmbd RCU Callback Race Condition Local Privilege Escalation Vulnerability
CVE-2023-32254:A flaw was found in the Linux kernel'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.
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().
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.
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.
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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6277" id="CVE-2023-6277" title="CVE-2023-6277" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6277" id="CVE-2023-6277" title="CVE-2023-6277" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6228" id="CVE-2023-6228" title="CVE-2023-6228" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1941" id="CVE-2022-1941" title="CVE-2022-1941" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5157" id="CVE-2023-5157" title="CVE-2023-5157" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47015" id="CVE-2022-47015" title="CVE-2022-47015" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38791" id="CVE-2022-38791" title="CVE-2022-38791" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0778" id="CVE-2022-0778" title="CVE-2022-0778" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32087" id="CVE-2022-32087" title="CVE-2022-32087" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32091" id="CVE-2022-32091" title="CVE-2022-32091" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32085" id="CVE-2022-32085" title="CVE-2022-32085" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32084" id="CVE-2022-32084" title="CVE-2022-32084" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32088" id="CVE-2022-32088" title="CVE-2022-32088" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32083" id="CVE-2022-32083" title="CVE-2022-32083" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-28912" id="CVE-2020-28912" title="CVE-2020-28912" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-2144" id="CVE-2021-2144" title="CVE-2021-2144" type="cve"/>
		</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.
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.
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.
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).
CVE-2022-32087:MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Item_args::walk_args.
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.
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.
CVE-2022-32084:MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component sub_select.
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.
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.
CVE-2020-28912:With MariaDB running on Windows, when local clients connect to the server over named pipes, it'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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23583" id="CVE-2023-23583" title="CVE-2023-23583" type="cve"/>
		</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>FusionOS</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22068" id="CVE-2023-22068" title="CVE-2023-22068" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38545" id="CVE-2023-38545" title="CVE-2023-38545" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22079" id="CVE-2023-22079" title="CVE-2023-22079" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22084" id="CVE-2023-22084" title="CVE-2023-22084" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22064" id="CVE-2023-22064" title="CVE-2023-22064" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22078" id="CVE-2023-22078" title="CVE-2023-22078" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22066" id="CVE-2023-22066" title="CVE-2023-22066" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22113" id="CVE-2023-22113" title="CVE-2023-22113" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22026" id="CVE-2023-22026" title="CVE-2023-22026" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22015" id="CVE-2023-22015" title="CVE-2023-22015" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22032" id="CVE-2023-22032" title="CVE-2023-22032" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22059" id="CVE-2023-22059" title="CVE-2023-22059" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22070" id="CVE-2023-22070" title="CVE-2023-22070" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22115" id="CVE-2023-22115" title="CVE-2023-22115" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22028" id="CVE-2023-22028" title="CVE-2023-22028" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22104" id="CVE-2023-22104" title="CVE-2023-22104" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22114" id="CVE-2023-22114" title="CVE-2023-22114" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22097" id="CVE-2023-22097" title="CVE-2023-22097" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22110" id="CVE-2023-22110" title="CVE-2023-22110" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22065" id="CVE-2023-22065" title="CVE-2023-22065" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22112" id="CVE-2023-22112" title="CVE-2023-22112" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22092" id="CVE-2023-22092" title="CVE-2023-22092" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22111" id="CVE-2023-22111" title="CVE-2023-22111" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22103" id="CVE-2023-22103" title="CVE-2023-22103" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22058" id="CVE-2023-22058" title="CVE-2023-22058" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22046" id="CVE-2023-22046" title="CVE-2023-22046" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22038" id="CVE-2023-22038" title="CVE-2023-22038" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22053" id="CVE-2023-22053" title="CVE-2023-22053" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22008" id="CVE-2023-22008" title="CVE-2023-22008" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22057" id="CVE-2023-22057" title="CVE-2023-22057" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22005" id="CVE-2023-22005" title="CVE-2023-22005" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22054" id="CVE-2023-22054" title="CVE-2023-22054" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22033" id="CVE-2023-22033" title="CVE-2023-22033" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22048" id="CVE-2023-22048" title="CVE-2023-22048" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22056" id="CVE-2023-22056" title="CVE-2023-22056" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22007" id="CVE-2023-22007" title="CVE-2023-22007" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43551" id="CVE-2022-43551" title="CVE-2022-43551" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21946" id="CVE-2023-21946" title="CVE-2023-21946" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21963" id="CVE-2023-21963" title="CVE-2023-21963" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21912" id="CVE-2023-21912" title="CVE-2023-21912" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21945" id="CVE-2023-21945" title="CVE-2023-21945" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21933" id="CVE-2023-21933" title="CVE-2023-21933" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21935" id="CVE-2023-21935" title="CVE-2023-21935" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21982" id="CVE-2023-21982" title="CVE-2023-21982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21955" id="CVE-2023-21955" title="CVE-2023-21955" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21929" id="CVE-2023-21929" title="CVE-2023-21929" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21966" id="CVE-2023-21966" title="CVE-2023-21966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21913" id="CVE-2023-21913" title="CVE-2023-21913" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21980" id="CVE-2023-21980" title="CVE-2023-21980" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21947" id="CVE-2023-21947" title="CVE-2023-21947" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21919" id="CVE-2023-21919" title="CVE-2023-21919" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21972" id="CVE-2023-21972" title="CVE-2023-21972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21962" id="CVE-2023-21962" title="CVE-2023-21962" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21917" id="CVE-2023-21917" title="CVE-2023-21917" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21977" id="CVE-2023-21977" title="CVE-2023-21977" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21940" id="CVE-2023-21940" title="CVE-2023-21940" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21911" id="CVE-2023-21911" title="CVE-2023-21911" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21976" id="CVE-2023-21976" title="CVE-2023-21976" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21953" id="CVE-2023-21953" title="CVE-2023-21953" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21920" id="CVE-2023-21920" title="CVE-2023-21920" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32221" id="CVE-2022-32221" title="CVE-2022-32221" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21836" id="CVE-2023-21836" title="CVE-2023-21836" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21871" id="CVE-2023-21871" title="CVE-2023-21871" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21865" id="CVE-2023-21865" title="CVE-2023-21865" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21872" id="CVE-2023-21872" title="CVE-2023-21872" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21867" id="CVE-2023-21867" title="CVE-2023-21867" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21873" id="CVE-2023-21873" title="CVE-2023-21873" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21864" id="CVE-2023-21864" title="CVE-2023-21864" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21870" id="CVE-2023-21870" title="CVE-2023-21870" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21874" id="CVE-2023-21874" title="CVE-2023-21874" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21868" id="CVE-2023-21868" title="CVE-2023-21868" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21863" id="CVE-2023-21863" title="CVE-2023-21863" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21869" id="CVE-2023-21869" title="CVE-2023-21869" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21882" id="CVE-2023-21882" title="CVE-2023-21882" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21881" id="CVE-2023-21881" title="CVE-2023-21881" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21883" id="CVE-2023-21883" title="CVE-2023-21883" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21887" id="CVE-2023-21887" title="CVE-2023-21887" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21880" id="CVE-2023-21880" title="CVE-2023-21880" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21879" id="CVE-2023-21879" title="CVE-2023-21879" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21875" id="CVE-2023-21875" title="CVE-2023-21875" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21876" id="CVE-2023-21876" title="CVE-2023-21876" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21877" id="CVE-2023-21877" title="CVE-2023-21877" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21878" id="CVE-2023-21878" title="CVE-2023-21878" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21592" id="CVE-2022-21592" title="CVE-2022-21592" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21641" id="CVE-2022-21641" title="CVE-2022-21641" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21638" id="CVE-2022-21638" title="CVE-2022-21638" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21635" id="CVE-2022-21635" title="CVE-2022-21635" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21611" id="CVE-2022-21611" title="CVE-2022-21611" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21625" id="CVE-2022-21625" title="CVE-2022-21625" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21599" id="CVE-2022-21599" title="CVE-2022-21599" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21632" id="CVE-2022-21632" title="CVE-2022-21632" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21633" id="CVE-2022-21633" title="CVE-2022-21633" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39400" id="CVE-2022-39400" title="CVE-2022-39400" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21640" id="CVE-2022-21640" title="CVE-2022-21640" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21608" id="CVE-2022-21608" title="CVE-2022-21608" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21594" id="CVE-2022-21594" title="CVE-2022-21594" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21617" id="CVE-2022-21617" title="CVE-2022-21617" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21637" id="CVE-2022-21637" title="CVE-2022-21637" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21604" id="CVE-2022-21604" title="CVE-2022-21604" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39410" id="CVE-2022-39410" title="CVE-2022-39410" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39408" id="CVE-2022-39408" title="CVE-2022-39408" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21569" id="CVE-2022-21569" title="CVE-2022-21569" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21526" id="CVE-2022-21526" title="CVE-2022-21526" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21528" id="CVE-2022-21528" title="CVE-2022-21528" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21525" id="CVE-2022-21525" title="CVE-2022-21525" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21531" id="CVE-2022-21531" title="CVE-2022-21531" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21537" id="CVE-2022-21537" title="CVE-2022-21537" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21538" id="CVE-2022-21538" title="CVE-2022-21538" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21539" id="CVE-2022-21539" title="CVE-2022-21539" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21509" id="CVE-2022-21509" title="CVE-2022-21509" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21553" id="CVE-2022-21553" title="CVE-2022-21553" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21529" id="CVE-2022-21529" title="CVE-2022-21529" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21534" id="CVE-2022-21534" title="CVE-2022-21534" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21515" id="CVE-2022-21515" title="CVE-2022-21515" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21547" id="CVE-2022-21547" title="CVE-2022-21547" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21522" id="CVE-2022-21522" title="CVE-2022-21522" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21527" id="CVE-2022-21527" title="CVE-2022-21527" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21530" id="CVE-2022-21530" title="CVE-2022-21530" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21517" id="CVE-2022-21517" title="CVE-2022-21517" type="cve"/>
		</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).
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.
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 &quot;let the host resolve the name&quot; 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.
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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.
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.
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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.
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-1971" id="CVE-2020-1971" title="CVE-2020-1971" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23840" id="CVE-2021-23840" title="CVE-2021-23840" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23841" id="CVE-2021-23841" title="CVE-2021-23841" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3449" id="CVE-2021-3449" title="CVE-2021-3449" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3450" id="CVE-2021-3450" title="CVE-2021-3450" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3711" id="CVE-2021-3711" title="CVE-2021-3711" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3712" id="CVE-2021-3712" title="CVE-2021-3712" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4160" id="CVE-2021-4160" title="CVE-2021-4160" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0778" id="CVE-2022-0778" title="CVE-2022-0778" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1292" id="CVE-2022-1292" title="CVE-2022-1292" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2068" id="CVE-2022-2068" title="CVE-2022-2068" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2097" id="CVE-2022-2097" title="CVE-2022-2097" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"/>
		</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' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function.
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.
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's s_server, s_client and verify tools have support for the &quot;-crl_download&quot; 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'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).
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).
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).
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).
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 &quot;purpose&quot; has been configured then there is a subsequent opportunity for checks that the certificate is a valid CA. All of the named &quot;purpose&quot; 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).
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 &quot;out&quot; parameter can be NULL and, on exit, the &quot;outlen&quot; 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 &quot;out&quot; 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).
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's own &quot;d2i&quot; 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 &quot;data&quot; and &quot;length&quot; 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 &quot;data&quot; 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).
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).
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).
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).
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).
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't written. In the special case of &quot;in place&quot; 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).
CVE-2022-4450:The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &quot;name&quot; (e.g. &quot;CERTIFICATE&quot;), any header data and the payload data. If the function succeeds then the &quot;name_out&quot;, &quot;header&quot; and &quot;data&quot; 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.
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.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43907" id="CVE-2023-43907" title="CVE-2023-43907" type="cve"/>
		</references>
		<description>CVE-2023-43907:OptiPNG v0.7.7 was discovered to contain a global buffer overflow via the 'buffer' variable at gifread.c.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47038" id="CVE-2023-47038" title="CVE-2023-47038" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36023" id="CVE-2020-36023" title="CVE-2020-36023" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49083" id="CVE-2023-49083" title="CVE-2023-49083" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49083" id="CVE-2023-49083" title="CVE-2023-49083" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46136" id="CVE-2023-46136" title="CVE-2023-46136" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1544" id="CVE-2023-1544" title="CVE-2023-1544" type="cve"/>
		</references>
		<description>CVE-2023-1544:A flaw was found in the QEMU implementation of VMWare'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43114" id="CVE-2023-43114" title="CVE-2023-43114" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38197" id="CVE-2023-38197" title="CVE-2023-38197" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37369" id="CVE-2023-37369" title="CVE-2023-37369" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38197" id="CVE-2023-38197" title="CVE-2023-38197" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43114" id="CVE-2023-43114" title="CVE-2023-43114" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25155" id="CVE-2023-25155" title="CVE-2023-25155" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45145" id="CVE-2023-45145" title="CVE-2023-45145" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29824" id="CVE-2023-29824" title="CVE-2023-29824" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"/>
		</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' argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()' function.
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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-11039" id="CVE-2018-11039" title="CVE-2018-11039" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22950" id="CVE-2022-22950" title="CVE-2022-22950" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49285" id="CVE-2023-49285" title="CVE-2023-49285" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49286" id="CVE-2023-49286" title="CVE-2023-49286" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39840" id="CVE-2023-39804" title="CVE-2023-39804" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46589" id="CVE-2023-46589" title="CVE-2023-46589" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42795" id="CVE-2023-42795" title="CVE-2023-42795" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48706" id="CVE-2023-48706" title="CVE-2023-48706" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48231" id="CVE-2023-48231" title="CVE-2023-48231" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48233" id="CVE-2023-48233" title="CVE-2023-48233" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48234" id="CVE-2023-48234" title="CVE-2023-48234" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48235" id="CVE-2023-48235" title="CVE-2023-48235" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48236" id="CVE-2023-48236" title="CVE-2023-48236" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48237" id="CVE-2023-48237" title="CVE-2023-48237" type="cve"/>
		</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.
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.
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.
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.
CVE-2023-48235:Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause an
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.
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
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2023-12-30"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6175" id="CVE-2023-6175" title="CVE-2023-6175" type="cve"/>
		</references>
		<description>CVE-2023-6175:A heap-based buffer overflow was found in Wireshark's NetScreen file parser. This issue may allow local arbitrary code execution via a crafted capture file.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45866" id="CVE-2023-45866" title="CVE-2023-45866" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50229" id="CVE-2023-50229" title="CVE-2023-50229" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50230" id="CVE-2023-50230" title="CVE-2023-50230" type="cve"/>
		</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.
CVE-2023-50229:VUL-0: CVE-2023-50229: bluez: BlueZ Phone Book Access Profile Heap-based Buffer Overflow Remote Code Execution Vulnerability.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50471" id="CVE-2023-50471" title="CVE-2023-50471" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50472" id="CVE-2023-50472" title="CVE-2023-50472" type="cve"/>
		</references>
		<description>CVE-2023-50471:cJSON v1.7.16 was discovered to contain a segmentation violation via the function cJSON_InsertItemInArray at cJSON.c.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37026" id="CVE-2022-37026" title="CVE-2022-37026" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49990" id="CVE-2023-49990" title="CVE-2023-49990" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49991" id="CVE-2023-49991" title="CVE-2023-49991" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49992" id="CVE-2023-49992" title="CVE-2023-49992" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49993" id="CVE-2023-49993" title="CVE-2023-49993" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49994" id="CVE-2023-49994" title="CVE-2023-49994" type="cve"/>
		</references>
		<description>CVE-2023-49990:Espeak-ng 1.52-dev was discovered to contain a buffer-overflow via the function SetUpPhonemeTable at synthdata.c.
CVE-2023-49991:Espeak-ng 1.52-dev was discovered to contain a Stack Buffer Underflow via the function CountVowelPosition at synthdata.c.
CVE-2023-49992:Espeak-ng 1.52-dev was discovered to contain a Stack Buffer Overflow via the function RemoveEnding at dictionary.c.
CVE-2023-49993:Espeak-ng 1.52-dev was discovered to contain a Buffer Overflow via the function ReadClause at readclause.c.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44446" id="CVE-2023-44446" title="CVE-2023-44446" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37329" id="CVE-2023-37329" title="CVE-2023-37329" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22742" id="CVE-2023-22742" title="CVE-2023-22742" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26592" id="CVE-2022-26592" title="CVE-2022-26592" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43358" id="CVE-2022-43358" title="CVE-2022-43358" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43357" id="CVE-2022-43357" title="CVE-2022-43357" type="cve"/>
		</references>
		<description>CVE-2022-26592:Stack Overflow vulnerability in libsass 3.6.5 via the CompoundSelector::has_real_parent_ref function.
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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6004" id="CVE-2023-6004" title="CVE-2023-6004" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6918" id="CVE-2023-6918" title="CVE-2023-6918" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6378" id="CVE-2023-6378" title="CVE-2023-6378" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6481" id="CVE-2023-6481" title="CVE-2023-6481" type="cve"/>
		</references>
		<description>CVE-2023-6378:A serialization vulnerability in logback receiver component part of 
logback version 1.4.11 allows an attacker to mount a Denial-Of-Service 
attack by sending poisoned data.
CVE-2023-6481:A serialization vulnerability in logback receiver component part of 
logback version 1.4.13, 1.3.13 and 1.2.12 allows an attacker to mount a Denial-Of-Service 
attack by sending poisoned data.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7104" id="CVE-2023-7104" title="CVE-2023-7104" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50269" id="CVE-2023-50269" title="CVE-2023-50269" type="cve"/>
		</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's patch archives.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41913" id="CVE-2023-41913" title="CVE-2023-41913" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42465" id="CVE-2023-42465" title="CVE-2023-42465" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7008" id="CVE-2023-7008" title="CVE-2023-7008" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="systemd" release="63.u16.fos23" version="249">
					<filename>systemd-249-63.u16.fos23.aarch64.rpm</filename>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4065" id="CVE-2022-4065" title="CVE-2022-4065" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33391" id="CVE-2021-33391" title="CVE-2021-33391" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6478" id="CVE-2023-6478" title="CVE-2023-6478" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6377" id="CVE-2023-6377" title="CVE-2023-6377" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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</release>
		<issued date="2024-01-31"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31975" id="CVE-2023-31975" title="CVE-2023-31975" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2019</id>
		<title>An update for ansible is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0690" id="CVE-2024-0690" title="CVE-2024-0690" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2020</id>
		<title>An update for apache-sshd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35887" id="CVE-2023-35887" title="CVE-2023-35887" type="cve"/>
		</references>
		<description>CVE-2023-35887:Exposure of Sensitive Information to an Unauthorized Actor vulnerability in Apache Software Foundation Apache MINA.
In SFTP servers implemented using Apache MINA SSHD that use a RootedFileSystem, logged users may be able to discover &quot;exists/does not exist&quot; information about items outside the rooted tree via paths including parent navigation (&quot;..&quot;) beyond the root, or involving symlinks.
This issue affects Apache MINA: from 1.0 before 2.10. Users are recommended to upgrade to 2.10</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2021</id>
		<title>An update for freerdp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22211" id="CVE-2024-22211" title="CVE-2024-22211" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2022</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0553" id="CVE-2024-0553" title="CVE-2024-0553" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0567" id="CVE-2024-0567" title="CVE-2024-0567" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2023</id>
		<title>An update for graphviz is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46045" id="CVE-2023-46045" title="CVE-2023-46045" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2024</id>
		<title>An update for hsqldb1 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41853" id="CVE-2022-41853" title="CVE-2022-41853" type="cve"/>
		</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 &quot;hsqldb.method_class_names&quot; to classes which are allowed to be called. For example, System.setProperty(&quot;hsqldb.method_class_names&quot;, &quot;abc&quot;) or Java argument -Dhsqldb.method_class_names=&quot;abc&quot; 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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2025</id>
		<title>An update for httpcomponents-client is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-13956" id="CVE-2020-13956" title="CVE-2020-13956" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2026</id>
		<title>An update for indent is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0911" id="CVE-2024-0911" title="CVE-2024-0911" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20922" id="CVE-2024-20922" title="CVE-2024-20922" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20945" id="CVE-2024-20945" title="CVE-2024-20945" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20952" id="CVE-2024-20952" title="CVE-2024-20952" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20926" id="CVE-2024-20926" title="CVE-2024-20926" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20925" id="CVE-2024-20925" title="CVE-2024-20925" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20919" id="CVE-2024-20919" title="CVE-2024-20919" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20921" id="CVE-2024-20921" title="CVE-2024-20921" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20923" id="CVE-2024-20923" title="CVE-2024-20923" type="cve"/>
		</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).
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).
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).
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).
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).
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).
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).
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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2028</id>
		<title>An update for jgit is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4759" id="CVE-2023-4759" title="CVE-2023-4759" type="cve"/>
		</references>
		<description>CVE-2023-4759:Arbitrary File Overwrite in Eclipse JGit &lt;= 6.6.0
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.
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.
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.
Setting git configuration option core.symlinks = false before checking out avoids the problem.
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.
The JGit maintainers would like to thank RyotaK for finding and reporting this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2029</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6932" id="CVE-2023-6932" title="CVE-2023-6932" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6817" id="CVE-2023-6817" title="CVE-2023-6817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6546" id="CVE-2023-6546" title="CVE-2023-6546" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6931" id="CVE-2023-6931" title="CVE-2023-6931" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6610" id="CVE-2023-6610" title="CVE-2023-6610" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6606" id="CVE-2023-6606" title="CVE-2023-6606" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35827" id="CVE-2023-35827" title="CVE-2023-35827" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51780" id="CVE-2023-51780" title="CVE-2023-51780" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33631" id="CVE-2021-33631" title="CVE-2021-33631" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51781" id="CVE-2023-51781" title="CVE-2023-51781" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51782" id="CVE-2023-51782" title="CVE-2023-51782" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6121" id="CVE-2023-6121" title="CVE-2023-6121" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51779" id="CVE-2023-51779" title="CVE-2023-51779" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6610" id="CVE-2023-6610" title="CVE-2023-6610" type="cve"/>
		</references>
		<description>CVE-2023-6932:A use-after-free vulnerability in the Linux kernel's ipv4: igmp component can be exploited to achieve local privilege escalation.
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.
We recommend upgrading past commit e2b706c691905fe78468c361aaabc719d0a496f1.
CVE-2023-6817:A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
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.
We recommend upgrading past commit 317eb9685095678f2c9f5a8189de698c5354316a.
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.
CVE-2023-6931:A heap out-of-bounds write vulnerability in the Linux kernel's Performance Events system component can be exploited to achieve local privilege escalation.
A perf_event's read_size can overflow, leading to an heap out-of-bounds increment or write in perf_read_group().
We recommend upgrading past commit 382c27f4ed28f803b1f1473ac2d8db0afc795a1b.
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.
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.
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.
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.
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.
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.
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.
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).
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 (&quot;skb&quot;). This flaw allows a local user to cause a denial of service condition or potential code execution.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2030</id>
		<title>An update for libgit2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24577" id="CVE-2024-24577" title="CVE-2024-24577" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2031</id>
		<title>An update for liblouis is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26981" id="CVE-2022-26981" title="CVE-2022-26981" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31783" id="CVE-2022-31783" title="CVE-2022-31783" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26767" id="CVE-2023-26767" title="CVE-2023-26767" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26768" id="CVE-2023-26768" title="CVE-2023-26768" type="cve"/>
		</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).
CVE-2022-31783:Liblouis 3.21.0 has an out-of-bounds write in compileRule in compileTranslationTable.c, as demonstrated by lou_trace.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2032</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25062" id="CVE-2024-25062" title="CVE-2024-25062" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2033</id>
		<title>An update for ncurses is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45918" id="CVE-2023-45918" title="CVE-2023-45918" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50495" id="CVE-2023-50495" title="CVE-2023-50495" type="cve"/>
		</references>
		<description>CVE-2023-45918:ncurses 6.4-20230610 has a NULL pointer dereference in tgetstr in tinfo/lib_termcap.c.
CVE-2023-50495:NCurse v6.4-20230418 was discovered to contain a segmentation fault via the component _nc_wrap_entry().</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2034</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51385" id="CVE-2023-51385" title="CVE-2023-51385" type="cve"/>
		</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'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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2035</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"/>
		</references>
		<description>CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL
to crash leading to a potential Denial of Service attack
Impact summary: Applications loading files in the PKCS12 format from untrusted
sources might terminate abruptly.
A file in PKCS12 format can contain certificates and keys and may come from an
untrusted source. The PKCS12 specification allows certain fields to be NULL, but
OpenSSL does not correctly check for this case. This can lead to a NULL pointer
dereference that results in OpenSSL crashing. If an application processes PKCS12
files from an untrusted source using the OpenSSL APIs then that application will
be vulnerable to this issue.
OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().
We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security significant.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2036</id>
		<title>An update for pam is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22365" id="CVE-2024-22365" title="CVE-2024-22365" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2037</id>
		<title>An update for proftpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51713" id="CVE-2023-51713" title="CVE-2023-51713" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"/>
		</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.
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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2038</id>
		<title>An update for python-jinja2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22195" id="CVE-2024-22195" title="CVE-2024-22195" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2039</id>
		<title>An update for python-jwcrypto is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3102" id="CVE-2022-3102" title="CVE-2022-3102" type="cve"/>
		</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.
Quoting the private disclosure we received : &quot;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.&quot; 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.
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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2040</id>
		<title>An update for python-pillow is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45198" id="CVE-2022-45198" title="CVE-2022-45198" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50447" id="CVE-2023-50447" title="CVE-2023-50447" type="cve"/>
		</references>
		<description>CVE-2022-45198:Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2041</id>
		<title>An update for python-pycryptodome is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52323" id="CVE-2023-52323" title="CVE-2023-52323" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2042</id>
		<title>An update for python-pycryptodomex is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52323" id="CVE-2023-52323" title="CVE-2023-52323" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2043</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51714" id="CVE-2023-51714" title="CVE-2023-51714" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2044</id>
		<title>An update for rear is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23301" id="CVE-2024-23301" title="CVE-2024-23301" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2045</id>
		<title>An update for rubygem-actionpack is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22792" id="CVE-2023-22792" title="CVE-2023-22792" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22795" id="CVE-2023-22795" title="CVE-2023-22795" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2046</id>
		<title>An update for rubygem-puma is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23634" id="CVE-2022-23634" title="CVE-2022-23634" type="cve"/>
		</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' 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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2047</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40547" id="CVE-2023-40547" title="CVE-2023-40547" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40548" id="CVE-2023-40548" title="CVE-2023-40548" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40549" id="CVE-2023-40549" title="CVE-2023-40549" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40550" id="CVE-2023-40550" title="CVE-2023-40550" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40551" id="CVE-2023-40551" title="CVE-2023-40551" type="cve"/>
		</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.
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.
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.
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's boot phase.
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's boot phase.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2048</id>
		<title>An update for sox is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33844" id="CVE-2021-33844" title="CVE-2021-33844" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32627" id="CVE-2023-32627" title="CVE-2023-32627" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23159" id="CVE-2021-23159" title="CVE-2021-23159" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34432" id="CVE-2023-34432" title="CVE-2023-34432" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34318" id="CVE-2023-34318" title="CVE-2023-34318" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23172" id="CVE-2021-23172" title="CVE-2021-23172" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3643" id="CVE-2021-3643" title="CVE-2021-3643" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23210" id="CVE-2021-23210" title="CVE-2021-23210" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31650" id="CVE-2022-31650" title="CVE-2022-31650" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26590" id="CVE-2023-26590" title="CVE-2023-26590" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31651" id="CVE-2022-31651" title="CVE-2022-31651" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32627" id="CVE-2023-32627" title="CVE-2023-32627" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-18189" id="CVE-2017-18189" title="CVE-2017-18189" type="cve"/>
		</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.
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.
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.
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.
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.
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.
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.
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.
CVE-2022-31650:In SoX 14.4.2, there is a floating-point exception in lsx_aiffstartwrite in aiff.c in libsox.a.
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.
CVE-2022-31651:In SoX 14.4.2, there is an assertion failure in rate_init in rate.c in libsox.a.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2049</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23638" id="CVE-2024-23638" title="CVE-2024-23638" type="cve"/>
		</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's patch archives. As a workaround, prevent access to Cache Manager using Squid's main access control: `http_access deny manager`.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2050</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24998" id="CVE-2023-24998" title="CVE-2023-24998" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28709" id="CVE-2023-28709" title="CVE-2023-28709" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42795" id="CVE-2023-42795" title="CVE-2023-42795" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21733" id="CVE-2024-21733" title="CVE-2024-21733" type="cve"/>
		</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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2051</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0208" id="CVE-2024-0208" title="CVE-2024-0208" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0209" id="CVE-2024-0209" title="CVE-2024-0209" type="cve"/>
		</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
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-02-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21885" id="CVE-2024-21885" title="CVE-2024-21885" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21886" id="CVE-2024-21886" title="CVE-2024-21886" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0408" id="CVE-2024-0408" title="CVE-2024-0408" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0409" id="CVE-2024-0409" title="CVE-2024-0409" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6816" id="CVE-2023-6816" title="CVE-2023-6816" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0229" id="CVE-2024-0229" title="CVE-2024-0229" type="cve"/>
		</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.
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.
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.
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.
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's particular number of buttons, leading to a heap overflow if a bigger value was used.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1062" id="CVE-2024-1062" title="CVE-2024-1062" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2054</id>
		<title>An update for OpenEXR is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5841" id="CVE-2023-5841" title="CVE-2023-5841" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2055</id>
		<title>An update for apache-mime4j is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21742" id="CVE-2024-21742" title="CVE-2024-21742" type="cve"/>
		</references>
		<description>CVE-2024-21742:Improper input validation allows for header injection in MIME4J library when using MIME4J DOM for composing message.
This can be exploited by an attacker to add unintended headers to MIME messages.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2056</id>
		<title>An update for apache-sshd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2057</id>
		<title>An update for atune-collector is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24897" id="CVE-2024-24897" title="CVE-2024-24897" type="cve"/>
		</references>
		<description>CVE-2024-24897:Improper Neutralization of Special Elements used in a Command ('Command Injection') 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.
This issue affects A-Tune-Collector: from 1.1.0-3 through 1.3.0.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2058</id>
		<title>An update for binutils is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25584" id="CVE-2023-25584" title="CVE-2023-25584" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2059</id>
		<title>An update for c-ares is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25629" id="CVE-2024-25629" title="CVE-2024-25629" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2060</id>
		<title>An update for derby is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46337" id="CVE-2022-46337" title="CVE-2022-46337" type="cve"/>
		</references>
		<description>CVE-2022-46337:A cleverly devised username might bypass LDAP authentication checks. In 
LDAP-authenticated Derby installations, this could let an attacker fill 
up the disk by creating junk Derby databases. In LDAP-authenticated 
Derby installations, this could also allow the attacker to execute 
malware which was visible to and executable by the account which booted 
the Derby server. In LDAP-protected databases which weren't also 
protected by SQL GRANT/REVOKE authorization, this vulnerability could 
also let an attacker view and corrupt sensitive data and run sensitive 
database functions and procedures.
Mitigation:
Users should upgrade to Java 21 and Derby 10.17.1.0.
Alternatively, users who wish to remain on older Java versions should 
build their own Derby distribution from one of the release families to 
which the fix was backported: 10.16, 10.15, and 10.14. Those are the 
releases which correspond, respectively, with Java LTS versions 17, 11, 
and 8.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2061</id>
		<title>An update for dhcp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2795" id="CVE-2022-2795" title="CVE-2022-2795" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38177" id="CVE-2022-38177" title="CVE-2022-38177" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38178" id="CVE-2022-38178" title="CVE-2022-38178" type="cve"/>
		</references>
		<description>CVE-2022-2795:By flooding the target resolver with queries exploiting this flaw an attacker can significantly impair the resolver's performance, effectively denying legitimate clients access to the DNS resolution service.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2062</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36763" id="CVE-2022-36763" title="CVE-2022-36763" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36764" id="CVE-2022-36764" title="CVE-2022-36764" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36765" id="CVE-2022-36765" title="CVE-2022-36765" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45229" id="CVE-2023-45229" title="CVE-2023-45229" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45230" id="CVE-2023-45230" title="CVE-2023-45230" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45231" id="CVE-2023-45231" title="CVE-2023-45231" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45232" id="CVE-2023-45232" title="CVE-2023-45232" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45233" id="CVE-2023-45233" title="CVE-2023-45233" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45234" id="CVE-2023-45234" title="CVE-2023-45234" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45235" id="CVE-2023-45235" title="CVE-2023-45235" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"/>
		</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.
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.
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.
CVE-2023-45229:EDK2's Network Package is susceptible to an out-of-bounds read
 vulnerability when processing the IA_NA or IA_TA option in a DHCPv6 Advertise message. This
 vulnerability can be exploited by an attacker to gain unauthorized 
access and potentially lead to a loss of Confidentiality.
CVE-2023-45230:EDK2's Network Package is susceptible to a buffer overflow vulnerability via a long server ID option in DHCPv6 client. This
 vulnerability can be exploited by an attacker to gain unauthorized 
access and potentially lead to a loss of Confidentiality, Integrity and/or Availability.
CVE-2023-45231:EDK2's Network Package is susceptible to an out-of-bounds read
 vulnerability when processing  Neighbor Discovery Redirect message. This
 vulnerability can be exploited by an attacker to gain unauthorized 
access and potentially lead to a loss of Confidentiality.
CVE-2023-45232:EDK2's Network Package is susceptible to an infinite loop vulnerability when parsing unknown options in the Destination Options header of IPv6. This
 vulnerability can be exploited by an attacker to gain unauthorized 
access and potentially lead to a loss of Availability.
CVE-2023-45233:EDK2's Network Package is susceptible to an infinite lop vulnerability when parsing a PadN option in the Destination Options header of IPv6. This
 vulnerability can be exploited by an attacker to gain unauthorized 
access and potentially lead to a loss of Availability.
CVE-2023-45234:EDK2's Network Package is susceptible to a buffer overflow vulnerability when processing DNS Servers option from a DHCPv6 Advertise message. This
 vulnerability can be exploited by an attacker to gain unauthorized 
access and potentially lead to a loss of Confidentiality, Integrity and/or Availability.
CVE-2023-45235:EDK2's Network Package is susceptible to a buffer overflow vulnerability when
handling Server ID option 
 from a DHCPv6 proxy Advertise message. This
 vulnerability can be exploited by an attacker to gain unauthorized 
access and potentially lead to a loss of Confidentiality, Integrity and/or Availability.
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' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
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' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
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.
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 'n' 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'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.
CVE-2023-3446:Issue summary: 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.
The function DH_check() performs various checks on DH parameters. One of those
checks confirms that the modulus ('p' parameter) is not too large. Trying to use
a very large modulus is slow and OpenSSL will not normally use a modulus which
is over 10,000 bits in length.
However the DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus value
even if it has already been found to be too large.
An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulernable to a Denial of Service attack.
The function DH_check() is itself called by a number of other OpenSSL functions.
An application calling any of those other functions may similarly be affected.
The other functions affected by this are DH_check_ex() and
EVP_PKEY_param_check().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
when using the '-check' option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2023-3817:Issue summary: 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.
The function DH_check() performs various checks on DH parameters. After fixing
CVE-2023-3446 it was discovered that a large q parameter value can also trigger
an overly long computation during some of these checks. A correct q value,
if present, cannot be larger than the modulus p parameter, thus it is
unnecessary to perform these checks if q is larger than p.
An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulnerable to a Denial of Service attack.
The function DH_check() is itself called by a number of other OpenSSL functions.
An application calling any of those other functions may similarly be affected.
The other functions affected by this are DH_check_ex() and
EVP_PKEY_param_check().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
when using the &quot;-check&quot; option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL
to crash leading to a potential Denial of Service attack
Impact summary: Applications loading files in the PKCS12 format from untrusted
sources might terminate abruptly.
A file in PKCS12 format can contain certificates and keys and may come from an
untrusted source. The PKCS12 specification allows certain fields to be NULL, but
OpenSSL does not correctly check for this case. This can lead to a NULL pointer
dereference that results in OpenSSL crashing. If an application processes PKCS12
files from an untrusted source using the OpenSSL APIs then that application will
be vulnerable to this issue.
OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().
We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security significant.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2063</id>
		<title>An update for erlang is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2064</id>
		<title>An update for firefox is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7104" id="CVE-2023-7104" title="CVE-2023-7104" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3479" id="CVE-2022-3479" title="CVE-2022-3479" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2065</id>
		<title>An update for fontforge is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25081" id="CVE-2024-25081" title="CVE-2024-25081" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25082" id="CVE-2024-25082" title="CVE-2024-25082" type="cve"/>
		</references>
		<description>CVE-2024-25081:Splinefont in FontForge through 20230101 allows command injection via crafted filenames.
CVE-2024-25082:Splinefont in FontForge through 20230101 allows command injection via crafted archives or compressed files.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="fontforge" release="8.u1.fos23" version="20200314">
					<filename>fontforge-20200314-8.u1.fos23.aarch64.rpm</filename>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2066</id>
		<title>An update for freeglut is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24258" id="CVE-2024-24258" title="CVE-2024-24258" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24259" id="CVE-2024-24259" title="CVE-2024-24259" type="cve"/>
		</references>
		<description>CVE-2024-24258:freeglut 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddSubMenu function.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2067</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46751" id="CVE-2023-46751" title="CVE-2023-46751" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2068</id>
		<title>An update for glade is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36774" id="CVE-2020-36774" title="CVE-2020-36774" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2069</id>
		<title>An update for glusterfs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48340" id="CVE-2022-48340" title="CVE-2022-48340" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2070</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39326" id="CVE-2023-39326" title="CVE-2023-39326" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45285" id="CVE-2023-45285" title="CVE-2023-45285" type="cve"/>
		</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.
CVE-2023-45285:Using go get to fetch a module with the &quot;.git&quot; suffix may unexpectedly fallback to the insecure &quot;git://&quot; protocol if the module is unavailable via the secure &quot;https://&quot; and &quot;git+ssh://&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2071</id>
		<title>An update for grub2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1048" id="CVE-2024-1048" title="CVE-2024-1048" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37327" id="CVE-2023-37327" title="CVE-2023-37327" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2073</id>
		<title>An update for hdf5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17433" id="CVE-2018-17433" title="CVE-2018-17433" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17436" id="CVE-2018-17436" title="CVE-2018-17436" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10809" id="CVE-2020-10809" title="CVE-2020-10809" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2074</id>
		<title>An update for jackson-databind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36518" id="CVE-2020-36518" title="CVE-2020-36518" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42003" id="CVE-2022-42003" title="CVE-2022-42003" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42004" id="CVE-2022-42004" title="CVE-2022-42004" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20919" id="CVE-2024-20919" title="CVE-2024-20919" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20952" id="CVE-2024-20952" title="CVE-2024-20952" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20945" id="CVE-2024-20945" title="CVE-2024-20945" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20921" id="CVE-2024-20921" title="CVE-2024-20921" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20926" id="CVE-2024-20926" title="CVE-2024-20926" type="cve"/>
		</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).
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).
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).
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).
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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2076</id>
		<title>An update for jersey is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28168" id="CVE-2021-28168" title="CVE-2021-28168" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2077</id>
		<title>An update for jruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28756" id="CVE-2023-28756" title="CVE-2023-28756" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2078</id>
		<title>An update for json-path is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51074" id="CVE-2023-51074" title="CVE-2023-51074" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2079</id>
		<title>An update for jsoup is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36033" id="CVE-2022-36033" title="CVE-2022-36033" type="cve"/>
		</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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2080</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23850" id="CVE-2024-23850" title="CVE-2024-23850" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7042" id="CVE-2023-7042" title="CVE-2023-7042" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52560" id="CVE-2023-52560" title="CVE-2023-52560" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6531" id="CVE-2023-6531" title="CVE-2023-6531" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0607" id="CVE-2024-0607" title="CVE-2024-0607" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6040" id="CVE-2023-6040" title="CVE-2023-6040" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0641" id="CVE-2024-0641" title="CVE-2024-0641" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0565" id="CVE-2024-0565" title="CVE-2024-0565" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0340" id="CVE-2024-0340" title="CVE-2024-0340" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22705" id="CVE-2024-22705" title="CVE-2024-22705" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46343" id="CVE-2023-46343" title="CVE-2023-46343" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51042" id="CVE-2023-51042" title="CVE-2023-51042" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6915" id="CVE-2023-6915" title="CVE-2023-6915" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51043" id="CVE-2023-51043" title="CVE-2023-51043" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52340" id="CVE-2023-52340" title="CVE-2023-52340" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23849" id="CVE-2024-23849" title="CVE-2024-23849" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46838" id="CVE-2023-46838" title="CVE-2023-46838" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0639" id="CVE-2024-0639" title="CVE-2024-0639" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1086" id="CVE-2024-1086" title="CVE-2024-1086" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0841" id="CVE-2024-0841" title="CVE-2024-0841" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52435" id="CVE-2023-52435" title="CVE-2023-52435" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23196" id="CVE-2024-23196" title="CVE-2024-23196" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50431" id="CVE-2023-50431" title="CVE-2023-50431" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6560" id="CVE-2023-6560" title="CVE-2023-6560" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6622" id="CVE-2023-6622" title="CVE-2023-6622" type="cve"/>
		</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.
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.
CVE-2023-52560:In the Linux kernel, the following vulnerability has been resolved:
mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
Since commit 9f86d624292c (&quot;mm/damon/vaddr-test: remove unnecessary
variables&quot;), the damon_destroy_ctx() is removed, but still call
damon_new_target() and damon_new_region(), the damon_region which is
allocated by kmem_cache_alloc() in damon_new_region() and the damon_target
which is allocated by kmalloc in damon_new_target() are not freed.  And
the damon_region which is allocated in damon_new_region() in
damon_set_regions() is also not freed.
So use damon_destroy_target to free all the damon_regions and damon_target.
    unreferenced object 0xffff888107c9a940 (size 64):
      comm &quot;kunit_try_catch&quot;, pid 1069, jiffies 4294670592 (age 732.761s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk
        60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff  `...............
      backtrace:
        [&lt;ffffffff817e0167&gt;] kmalloc_trace+0x27/0xa0
        [&lt;ffffffff819c11cf&gt;] damon_new_target+0x3f/0x1b0
        [&lt;ffffffff819c7d55&gt;] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
        [&lt;ffffffff819c82be&gt;] damon_test_apply_three_regions1+0x21e/0x260
        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90
        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380
        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70
        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20
    unreferenced object 0xffff8881079cc740 (size 56):
      comm &quot;kunit_try_catch&quot;, pid 1069, jiffies 4294670592 (age 732.761s)
      hex dump (first 32 bytes):
        05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................
        6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk
      backtrace:
        [&lt;ffffffff819bc492&gt;] damon_new_region+0x22/0x1c0
        [&lt;ffffffff819c7d91&gt;] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
        [&lt;ffffffff819c82be&gt;] damon_test_apply_three_regions1+0x21e/0x260
        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90
        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380
        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70
        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20
    unreferenced object 0xffff888107c9ac40 (size 64):
      comm &quot;kunit_try_catch&quot;, pid 1071, jiffies 4294670595 (age 732.843s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk
        a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff  ........x.v.....
      backtrace:
        [&lt;ffffffff817e0167&gt;] kmalloc_trace+0x27/0xa0
        [&lt;ffffffff819c11cf&gt;] damon_new_target+0x3f/0x1b0
        [&lt;ffffffff819c7d55&gt;] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
        [&lt;ffffffff819c851e&gt;] damon_test_apply_three_regions2+0x21e/0x260
        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90
        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380
        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70
        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20
    unreferenced object 0xffff8881079ccc80 (size 56):
      comm &quot;kunit_try_catch&quot;, pid 1071, jiffies 4294670595 (age 732.843s)
      hex dump (first 32 bytes):
        05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................
        6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk
      backtrace:
        [&lt;ffffffff819bc492&gt;] damon_new_region+0x22/0x1c0
        [&lt;ffffffff819c7d91&gt;] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
        [&lt;ffffffff819c851e&gt;] damon_test_apply_three_regions2+0x21e/0x260
        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90
        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380
        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70
        [&lt;ffff
---truncated---
CVE-2023-6531:A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector's deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
CVE-2023-52340:A flaw in the routing table size was found in the ICMPv6 handling of &quot;Packet Too Big&quot;. The size of the routing table is regulated by periodic garbage collection. However, with &quot;Packet Too Big Messages&quot; 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%.
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.
CVE-2023-46838:Transmit requests in Xen's virtual network protocol can consist of
multiple parts.  While not really useful, except for the initial part
any of them may be of zero length, i.e. carry no data at all.  Besides a
certain initial portion of the to be transferred data, these parts are
directly translated into what Linux calls SKB fragments.  Such converted
request parts can, when for a particular SKB they are all of length
zero, lead to a de-reference of NULL in core networking code.
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.
CVE-2024-1086:A use-after-free vulnerability in the Linux kernel's netfilter: nf_tables component can be exploited to achieve local privilege escalation.
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.
We recommend upgrading past commit f342de4e2f33e0e39165d8639387aa6c19dff660.
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.
CVE-2023-52435:In the Linux kernel, the following vulnerability has been resolved:
net: prevent mss overflow in skb_segment()
Once again syzbot is able to crash the kernel in skb_segment() [1]
GSO_BY_FRAGS is a forbidden value, but unfortunately the following
computation in skb_segment() can reach it quite easily :
	mss = mss * partial_segs;
65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead to
a bad final result.
Make sure to limit segmentation so that the new mss value is smaller
than GSO_BY_FRAGS.
[1]
general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]
CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
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
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffff
R10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0
R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046
FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;TASK&gt;
udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109
ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120
skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53
__skb_gso_segment+0x339/0x710 net/core/gso.c:124
skb_gso_segment include/net/gso.h:83 [inline]
validate_xmit_skb+0x36c/0xeb0 net/core/dev.c:3626
__dev_queue_xmit+0x6f3/0x3d60 net/core/dev.c:4338
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
packet_xmit+0x257/0x380 net/packet/af_packet.c:276
packet_snd net/packet/af_packet.c:3087 [inline]
packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg+0xd5/0x180 net/socket.c:745
__sys_sendto+0x255/0x340 net/socket.c:2190
__do_sys_sendto net/socket.c:2202 [inline]
__se_sys_sendto net/socket.c:2198 [inline]
__x64_sys_sendto+0xe0/0x1b0 net/socket.c:2198
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7f8692032aa9
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
RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9
RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003
RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014
R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480
R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003
&lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---
RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551
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
RSP: 0018:ffffc900043473d0 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597
RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070
RBP: ffffc90004347578 R0
---truncated---
CVE-2024-23196:A race condition was found in the Linux kernel'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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2081</id>
		<title>An update for less is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48624" id="CVE-2022-48624" title="CVE-2022-48624" type="cve"/>
		</references>
		<description>CVE-2022-48624:close_altfile in filename.c in less before 606 omits shell_quote calls for LESSCLOSE.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="less" release="5.u2.fos23" version="590">
					<filename>less-590-5.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2082</id>
		<title>An update for libexif is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-0452" id="CVE-2020-0452" title="CVE-2020-0452" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2083</id>
		<title>An update for libssh is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2084</id>
		<title>An update for libssh2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2085</id>
		<title>An update for libuv is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24806" id="CVE-2024-24806" title="CVE-2024-24806" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2086</id>
		<title>An update for linux-sgx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"/>
		</references>
		<description>CVE-2022-4450:The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and
decodes the &quot;name&quot; (e.g. &quot;CERTIFICATE&quot;), any header data and the payload data.
If the function succeeds then the &quot;name_out&quot;, &quot;header&quot; and &quot;data&quot; 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.
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.
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.
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' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
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' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
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.
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 'n' 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'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.
CVE-2023-3446:Issue summary: 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.
The function DH_check() performs various checks on DH parameters. One of those
checks confirms that the modulus ('p' parameter) is not too large. Trying to use
a very large modulus is slow and OpenSSL will not normally use a modulus which
is over 10,000 bits in length.
However the DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus value
even if it has already been found to be too large.
An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulernable to a Denial of Service attack.
The function DH_check() is itself called by a number of other OpenSSL functions.
An application calling any of those other functions may similarly be affected.
The other functions affected by this are DH_check_ex() and
EVP_PKEY_param_check().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
when using the '-check' option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2023-3817:Issue summary: 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.
The function DH_check() performs various checks on DH parameters. After fixing
CVE-2023-3446 it was discovered that a large q parameter value can also trigger
an overly long computation during some of these checks. A correct q value,
if present, cannot be larger than the modulus p parameter, thus it is
unnecessary to perform these checks if q is larger than p.
An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulnerable to a Denial of Service attack.
The function DH_check() is itself called by a number of other OpenSSL functions.
An application calling any of those other functions may similarly be affected.
The other functions affected by this are DH_check_ex() and
EVP_PKEY_param_check().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
when using the &quot;-check&quot; option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2023-5678:Issue summary: Generating excessively long X9.42 DH keys or checking
excessively long X9.42 DH keys or parameters may be very slow.
Impact summary: 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.
While DH_check() performs all the necessary checks (as of CVE-2023-3817),
DH_check_pub_key() doesn't make any of these checks, and is therefore
vulnerable for excessively large P and Q parameters.
Likewise, while DH_generate_key() performs a check for an excessively large
P, it doesn't check for an excessively large Q.
An application that calls DH_generate_key() or DH_check_pub_key() and
supplies a key or parameters obtained from an untrusted source could be
vulnerable to a Denial of Service attack.
DH_generate_key() and DH_check_pub_key() are also called by a number of
other OpenSSL functions.  An application calling any of those other
functions may similarly be affected.  The other functions affected by this
are DH_check_pub_key_ex(), EVP_PKEY_public_check(), and EVP_PKEY_generate().
Also vulnerable are the OpenSSL pkey command line application when using the
&quot;-pubcheck&quot; option, as well as the OpenSSL genpkey command line application.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24814" id="CVE-2024-24814" title="CVE-2024-24814" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0437" id="CVE-2023-0437" title="CVE-2023-0437" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-2471" id="CVE-2021-2471" title="CVE-2021-2471" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21363" id="CVE-2022-21363" title="CVE-2022-21363" type="cve"/>
		</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).
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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2090</id>
		<title>An update for netty is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41881" id="CVE-2022-41881" title="CVE-2022-41881" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4586" id="CVE-2023-4586" title="CVE-2023-4586" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2091</id>
		<title>An update for nodejs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"/>
		</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' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
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' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2092</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"/>
		</references>
		<description>CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL
to crash leading to a potential Denial of Service attack
Impact summary: Applications loading files in the PKCS12 format from untrusted
sources might terminate abruptly.
A file in PKCS12 format can contain certificates and keys and may come from an
untrusted source. The PKCS12 specification allows certain fields to be NULL, but
OpenSSL does not correctly check for this case. This can lead to a NULL pointer
dereference that results in OpenSSL crashing. If an application processes PKCS12
files from an untrusted source using the OpenSSL APIs then that application will
be vulnerable to this issue.
OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().
We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security significant.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2093</id>
		<title>An update for openresty-zlib is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37434" id="CVE-2022-37434" title="CVE-2022-37434" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2094</id>
		<title>An update for openvswitch is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3966" id="CVE-2023-3966" title="CVE-2023-3966" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2095</id>
		<title>An update for perl is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47039" id="CVE-2023-47039" title="CVE-2023-47039" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47100" id="CVE-2023-47100" title="CVE-2023-47100" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2096</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39417" id="CVE-2023-39417" title="CVE-2023-39417" type="cve"/>
		</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, '', or &quot;&quot;). 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2097</id>
		<title>An update for postgresql-jdbc is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1597" id="CVE-2024-1597" title="CVE-2024-1597" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2098</id>
		<title>An update for python-jwcrypto is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6681" id="CVE-2023-6681" title="CVE-2023-6681" type="cve"/>
		</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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2099</id>
		<title>An update for python-paramiko is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2100</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5088" id="CVE-2023-5088" title="CVE-2023-5088" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0330" id="CVE-2023-0330" title="CVE-2023-0330" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3019" id="CVE-2023-3019" title="CVE-2023-3019" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6693" id="CVE-2023-6693" title="CVE-2023-6693" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6683" id="CVE-2023-6683" title="CVE-2023-6683" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24474" id="CVE-2024-24474" title="CVE-2024-24474" type="cve"/>
		</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'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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2101</id>
		<title>An update for rubygem-activestorage is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26144" id="CVE-2024-26144" title="CVE-2024-26144" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2102</id>
		<title>An update for rubygem-yard is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27285" id="CVE-2024-27285" title="CVE-2024-27285" type="cve"/>
		</references>
		<description>CVE-2024-27285:YARD is a Ruby Documentation tool. The &quot;frames.html&quot; file within the Yard Doc's generated documentation is vulnerable to Cross-Site Scripting (XSS) attacks due to inadequate sanitization of user input within the JavaScript segment of the &quot;frames.erb&quot; template file.  This vulnerability is fixed in 0.9.36.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2103</id>
		<title>An update for runc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21626" id="CVE-2024-21626" title="CVE-2024-21626" type="cve"/>
		</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 (&quot;attack 2&quot;). 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 (&quot;attack 1&quot;). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes (&quot;attack 3a&quot; and &quot;attack 3b&quot;). runc 1.1.12 includes patches for this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2104</id>
		<title>An update for rust is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24577" id="CVE-2024-24577" title="CVE-2024-24577" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2105</id>
		<title>An update for samba is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14628" id="CVE-2018-14628" title="CVE-2018-14628" type="cve"/>
		</references>
		<description>CVE-2018-14628:An information leak vulnerability was discovered in Samba'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2106</id>
		<title>An update for shim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"/>
		</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' argument to the command line utilities or by calling the
`X509_VERIFY_PARAM_set1_policies()' function.
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 'n' 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'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.
CVE-2023-3446:Issue summary: 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.
The function DH_check() performs various checks on DH parameters. One of those
checks confirms that the modulus ('p' parameter) is not too large. Trying to use
a very large modulus is slow and OpenSSL will not normally use a modulus which
is over 10,000 bits in length.
However the DH_check() function checks numerous aspects of the key or parameters
that have been supplied. Some of those checks use the supplied modulus value
even if it has already been found to be too large.
An application that calls DH_check() and supplies a key or parameters obtained
from an untrusted source could be vulernable to a Denial of Service attack.
The function DH_check() is itself called by a number of other OpenSSL functions.
An application calling any of those other functions may similarly be affected.
The other functions affected by this are DH_check_ex() and
EVP_PKEY_param_check().
Also vulnerable are the OpenSSL dhparam and pkeyparam command line applications
when using the '-check' option.
The OpenSSL SSL/TLS implementation is not affected by this issue.
The OpenSSL 3.0 and 3.1 FIPS providers are not affected by this issue.
CVE-2024-0727:Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSL
to crash leading to a potential Denial of Service attack
Impact summary: Applications loading files in the PKCS12 format from untrusted
sources might terminate abruptly.
A file in PKCS12 format can contain certificates and keys and may come from an
untrusted source. The PKCS12 specification allows certain fields to be NULL, but
OpenSSL does not correctly check for this case. This can lead to a NULL pointer
dereference that results in OpenSSL crashing. If an application processes PKCS12
files from an untrusted source using the OpenSSL APIs then that application will
be vulnerable to this issue.
OpenSSL APIs that are vulnerable to this are: PKCS12_parse(),
PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes()
and PKCS12_newpass().
We have also fixed a similar issue in SMIME_write_PKCS7(). However since this
function is related to writing data we do not consider it security significant.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2107</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25617" id="CVE-2024-25617" title="CVE-2024-25617" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2108</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50387" id="CVE-2023-50387" title="CVE-2023-50387" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1488" id="CVE-2024-1488" title="CVE-2024-1488" type="cve"/>
		</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 &quot;KeyTrap&quot; 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.
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 &quot;NSEC3&quot; issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2109</id>
		<title>An update for varnish is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45059" id="CVE-2022-45059" title="CVE-2022-45059" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2110</id>
		<title>An update for wpa_supplicant is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52160" id="CVE-2023-52160" title="CVE-2023-52160" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2111</id>
		<title>An update for xerces-c is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-1311" id="CVE-2018-1311" title="CVE-2018-1311" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6816" id="CVE-2023-6816" title="CVE-2023-6816" type="cve"/>
		</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's particular number of buttons, leading to a heap overflow if a bigger value was used.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2113</id>
		<title>An update for xstream is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-03-26"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40151" id="CVE-2022-40151" title="CVE-2022-40151" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41966" id="CVE-2022-41966" title="CVE-2022-41966" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2114</id>
		<title>An update for LibRaw is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32142" id="CVE-2021-32142" title="CVE-2021-32142" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2115</id>
		<title>An update for OpenEXR is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31047" id="CVE-2024-31047" title="CVE-2024-31047" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2116</id>
		<title>An update for aspell is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-25051" id="CVE-2019-25051" title="CVE-2019-25051" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2117</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4408" id="CVE-2023-4408" title="CVE-2023-4408" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5517" id="CVE-2023-5517" title="CVE-2023-5517" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5679" id="CVE-2023-5679" title="CVE-2023-5679" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5680" id="CVE-2023-5680" title="CVE-2023-5680" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6516" id="CVE-2023-6516" title="CVE-2023-6516" type="cve"/>
		</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.
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.
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 &quot;NSEC3&quot; issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.
CVE-2023-5517:A flaw in query-handling code can cause `named` to exit prematurely with an assertion failure when:
  - `nxdomain-redirect &lt;domain&gt;;` is configured, and
  - the resolver receives a PTR query for an RFC 1918 address that would normally result in an authoritative NXDOMAIN response.
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.
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.
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.
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. 
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2118</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2398" id="CVE-2024-2398" title="CVE-2024-2398" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2119</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"/>
		</references>
		<description>CVE-2024-2511:Issue summary: Some non-default TLS server configurations can cause unbounded
memory growth when processing TLSv1.3 sessions
Impact summary: An attacker may exploit certain server configurations to trigger
unbounded memory growth that would lead to a Denial of Service
This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is
being used (but not if early_data support is also configured and the default
anti-replay protection is in use). In this case, under certain conditions, the
session cache can get into an incorrect state and it will fail to flush properly
as it fills. The session cache will continue to grow in an unbounded manner. A
malicious client could deliberately create the scenario for this failure to
force a Denial of Service. It may also happen by accident in normal operation.
This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS
clients.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
1.0.2 is also not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2120</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30203" id="CVE-2024-30203" title="CVE-2024-30203" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30204" id="CVE-2024-30204" title="CVE-2024-30204" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30205" id="CVE-2024-30205" title="CVE-2024-30205" type="cve"/>
		</references>
		<description>CVE-2024-30203:In Emacs before 29.3, Gnus treats inline MIME contents as trusted.
CVE-2024-30204:In Emacs before 29.3, LaTeX preview is enabled by default for e-mail attachments.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2121</id>
		<title>An update for expat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52426" id="CVE-2023-52426" title="CVE-2023-52426" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28757" id="CVE-2024-28757" title="CVE-2024-28757" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52425" id="CVE-2023-52425" title="CVE-2023-52425" type="cve"/>
		</references>
		<description>CVE-2023-52426:libexpat through 2.5.0 allows recursive XML Entity Expansion if XML_DTD is undefined at compile time.
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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2122</id>
		<title>An update for flatpak is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32462" id="CVE-2024-32462" title="CVE-2024-32462" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28100" id="CVE-2023-28100" title="CVE-2023-28100" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28101" id="CVE-2023-28101" title="CVE-2023-28101" type="cve"/>
		</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'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.
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't run Flatpak on a Linux virtual console. Flatpak is primarily designed to be used in a Wayland or X11 graphical environment.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2123</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2961" id="CVE-2024-2961" title="CVE-2024-2961" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2124</id>
		<title>An update for gnutls is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28835" id="CVE-2024-28835" title="CVE-2024-28835" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28834" id="CVE-2024-28834" title="CVE-2024-28834" type="cve"/>
		</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 &quot;certtool --verify-chain&quot; command.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2125</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27316" id="CVE-2024-27316" title="CVE-2024-27316" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2126</id>
		<title>An update for iperf3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7250" id="CVE-2023-7250" title="CVE-2023-7250" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2127</id>
		<title>An update for jose is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50967" id="CVE-2023-50967" title="CVE-2023-50967" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="jose" release="2.u1.fos23" version="11">
					<filename>jose-11-2.u1.fos23.aarch64.rpm</filename>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2128</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1151" id="CVE-2024-1151" title="CVE-2024-1151" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52443" id="CVE-2023-52443" title="CVE-2023-52443" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52463" id="CVE-2023-52463" title="CVE-2023-52463" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26598" id="CVE-2024-26598" title="CVE-2024-26598" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52448" id="CVE-2023-52448" title="CVE-2023-52448" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26595" id="CVE-2024-26595" title="CVE-2024-26595" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52436" id="CVE-2023-52436" title="CVE-2023-52436" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23850" id="CVE-2024-23850" title="CVE-2024-23850" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52438" id="CVE-2023-52438" title="CVE-2023-52438" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26583" id="CVE-2024-26583" title="CVE-2024-26583" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52439" id="CVE-2023-52439" title="CVE-2023-52439" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52522" id="CVE-2023-52522" title="CVE-2023-52522" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52573" id="CVE-2023-52573" title="CVE-2023-52573" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22099" id="CVE-2024-22099" title="CVE-2024-22099" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23851" id="CVE-2024-23851" title="CVE-2024-23851" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52510" id="CVE-2023-52510" title="CVE-2023-52510" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52458" id="CVE-2023-52458" title="CVE-2023-52458" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47014" id="CVE-2021-47014" title="CVE-2021-47014" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47036" id="CVE-2021-47036" title="CVE-2021-47036" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52566" id="CVE-2023-52566" title="CVE-2023-52566" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47028" id="CVE-2021-47028" title="CVE-2021-47028" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52568" id="CVE-2023-52568" title="CVE-2023-52568" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52449" id="CVE-2023-52449" title="CVE-2023-52449" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52447" id="CVE-2023-52447" title="CVE-2023-52447" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52452" id="CVE-2023-52452" title="CVE-2023-52452" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52451" id="CVE-2023-52451" title="CVE-2023-52451" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52583" id="CVE-2023-52583" title="CVE-2023-52583" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52606" id="CVE-2023-52606" title="CVE-2023-52606" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52486" id="CVE-2023-52486" title="CVE-2023-52486" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46987" id="CVE-2021-46987" title="CVE-2021-46987" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52507" id="CVE-2023-52507" title="CVE-2023-52507" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52515" id="CVE-2023-52515" title="CVE-2023-52515" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26586" id="CVE-2024-26586" title="CVE-2024-26586" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47076" id="CVE-2021-47076" title="CVE-2021-47076" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52524" id="CVE-2023-52524" title="CVE-2023-52524" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52527" id="CVE-2023-52527" title="CVE-2023-52527" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52445" id="CVE-2023-52445" title="CVE-2023-52445" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52500" id="CVE-2023-52500" title="CVE-2023-52500" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52528" id="CVE-2023-52528" title="CVE-2023-52528" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52488" id="CVE-2023-52488" title="CVE-2023-52488" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52602" id="CVE-2023-52602" title="CVE-2023-52602" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52603" id="CVE-2023-52603" title="CVE-2023-52603" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52593" id="CVE-2023-52593" title="CVE-2023-52593" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52604" id="CVE-2023-52604" title="CVE-2023-52604" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26627" id="CVE-2024-26627" title="CVE-2024-26627" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52494" id="CVE-2023-52494" title="CVE-2023-52494" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26624" id="CVE-2024-26624" title="CVE-2024-26624" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26625" id="CVE-2024-26625" title="CVE-2024-26625" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52502" id="CVE-2023-52502" title="CVE-2023-52502" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26622" id="CVE-2024-26622" title="CVE-2024-26622" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52599" id="CVE-2023-52599" title="CVE-2023-52599" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52600" id="CVE-2023-52600" title="CVE-2023-52600" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52622" id="CVE-2023-52622" title="CVE-2023-52622" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23307" id="CVE-2024-23307" title="CVE-2024-23307" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47094" id="CVE-2021-47094" title="CVE-2021-47094" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52601" id="CVE-2023-52601" title="CVE-2023-52601" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46926" id="CVE-2021-46926" title="CVE-2021-46926" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52479" id="CVE-2023-52479" title="CVE-2023-52479" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52484" id="CVE-2023-52484" title="CVE-2023-52484" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26593" id="CVE-2024-26593" title="CVE-2024-26593" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26788" id="CVE-2024-26788" title="CVE-2024-26788" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26607" id="CVE-2024-26607" title="CVE-2024-26607" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26773" id="CVE-2024-26773" title="CVE-2024-26773" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52469" id="CVE-2023-52469" title="CVE-2023-52469" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52475" id="CVE-2023-52475" title="CVE-2023-52475" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26600" id="CVE-2024-26600" title="CVE-2024-26600" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47037" id="CVE-2021-47037" title="CVE-2021-47037" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52456" id="CVE-2023-52456" title="CVE-2023-52456" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26696" id="CVE-2024-26696" title="CVE-2024-26696" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52467" id="CVE-2023-52467" title="CVE-2023-52467" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26608" id="CVE-2024-26608" title="CVE-2024-26608" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26589" id="CVE-2024-26589" title="CVE-2024-26589" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26597" id="CVE-2024-26597" title="CVE-2024-26597" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26606" id="CVE-2024-26606" title="CVE-2024-26606" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52477" id="CVE-2023-52477" title="CVE-2023-52477" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52454" id="CVE-2023-52454" title="CVE-2023-52454" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52476" id="CVE-2023-52476" title="CVE-2023-52476" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26654" id="CVE-2024-26654" title="CVE-2024-26654" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26603" id="CVE-2024-26603" title="CVE-2024-26603" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26644" id="CVE-2024-26644" title="CVE-2024-26644" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2639" id="CVE-2022-2639" title="CVE-2022-2639" type="cve"/>
		</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.
CVE-2023-52443:In the Linux kernel, the following vulnerability has been resolved:
apparmor: avoid crash when parsed profile name is empty
When processing a packed profile in unpack_profile() described like
 &quot;profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}&quot;
a string &quot;:samba-dcerpcd&quot; is unpacked as a fully-qualified name and then
passed to aa_splitn_fqname().
aa_splitn_fqname() treats &quot;:samba-dcerpcd&quot; as only containing a namespace.
Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Later
aa_alloc_profile() crashes as the new profile name is NULL now.
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
RIP: 0010:strlen+0x1e/0xa0
Call Trace:
 &lt;TASK&gt;
 ? strlen+0x1e/0xa0
 aa_policy_init+0x1bb/0x230
 aa_alloc_profile+0xb1/0x480
 unpack_profile+0x3bc/0x4960
 aa_unpack+0x309/0x15e0
 aa_replace_profiles+0x213/0x33c0
 policy_update+0x261/0x370
 profile_replace+0x20e/0x2a0
 vfs_write+0x2af/0xe00
 ksys_write+0x126/0x250
 do_syscall_64+0x46/0xf0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
 &lt;/TASK&gt;
---[ end trace 0000000000000000 ]---
RIP: 0010:strlen+0x1e/0xa0
It seems such behaviour of aa_splitn_fqname() is expected and checked in
other places where it is called (e.g. aa_remove_profiles). Well, there
is an explicit comment &quot;a ns name without a following profile is allowed&quot;
inside.
AFAICS, nothing can prevent unpacked &quot;name&quot; to be in form like
&quot;:samba-dcerpcd&quot; - it is passed from userspace.
Deny the whole profile set replacement in such case and inform user with
EPROTO and an explaining message.
Found by Linux Verification Center (linuxtesting.org).
CVE-2023-52463:In the Linux kernel, the following vulnerability has been resolved:
efivarfs: force RO when remounting if SetVariable is not supported
If SetVariable at runtime is not supported by the firmware we never assign
a callback for that function. At the same time mount the efivarfs as
RO so no one can call that.  However, we never check the permission flags
when someone remounts the filesystem as RW. As a result this leads to a
crash looking like this:
$ mount -o remount,rw /sys/firmware/efi/efivars
$ efi-updatevar -f PK.auth PK
[  303.279166] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
[  303.280482] Mem abort info:
[  303.280854]   ESR = 0x0000000086000004
[  303.281338]   EC = 0x21: IABT (current EL), IL = 32 bits
[  303.282016]   SET = 0, FnV = 0
[  303.282414]   EA = 0, S1PTW = 0
[  303.282821]   FSC = 0x04: level 0 translation fault
[  303.283771] user pgtable: 4k pages, 48-bit VAs, pgdp=000000004258c000
[  303.284913] [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
[  303.286076] Internal error: Oops: 0000000086000004 [#1] PREEMPT SMP
[  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
[  303.288586] CPU: 1 PID: 755 Comm: efi-updatevar Not tainted 6.3.0-rc1-00108-gc7d0c4695c68 #1
[  303.289748] Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.04-00627-g88336918701d 04/01/2023
[  303.291150] pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  303.292123] pc : 0x0
[  303.292443] lr : efivar_set_variable_locked+0x74/0xec
[  303.293156] sp : ffff800008673c10
[  303.293619] x29: ffff800008673c10 x28: ffff0000037e8000 x27: 0000000000000000
[  303.294592] x26: 0000000000000800 x25: ffff000002467400 x24: 0000000000000027
[  303.295572] x23: ffffd49ea9832000 x22: ffff0000020c9800 x21: ffff000002467000
[  303.296566] x20: 0000000000000001 x19: 00000000000007fc x18: 0000000000000000
[  303.297531] x17: 0000000000000000 x16: 0000000000000000 x15: 0000aaaac807ab54
[  303.298495] x14: ed37489f673633c0 x13: 71c45c606de13f80 x12: 47464259e219acf4
[  303.299453] x11: ffff000002af7b01 x10: 0000000000000003 x9 : 0000000000000002
[  303.300431] x8 : 0000000000000010 x7 : ffffd49ea8973230 x6 : 0000000000a85201
[  303.301412] x5 : 0000000000000000 x4 : ffff0000020c9800 x3 : 00000000000007fc
[  303.302370] x2 : 0000000000000027 x1 : ffff000002467400 x0 : ffff000002467000
[  303.303341] Call trace:
[  303.303679]  0x0
[  303.303938]  efivar_entry_set_get_size+0x98/0x16c
[  303.304585]  efivarfs_file_write+0xd0/0x1a4
[  303.305148]  vfs_write+0xc4/0x2e4
[  303.305601]  ksys_write+0x70/0x104
[  303.306073]  __arm64_sys_write+0x1c/0x28
[  303.306622]  invoke_syscall+0x48/0x114
[  303.307156]  el0_svc_common.constprop.0+0x44/0xec
[  303.307803]  do_el0_svc+0x38/0x98
[  303.308268]  el0_svc+0x2c/0x84
[  303.308702]  el0t_64_sync_handler+0xf4/0x120
[  303.309293]  el0t_64_sync+0x190/0x194
[  303.309794] Code: ???????? ???????? ???????? ???????? (????????)
[  303.310612] ---[ end trace 0000000000000000 ]---
Fix this by adding a .reconfigure() function to the fs operations which
we can use to check the requested flags and deny anything that's not RO
if the firmware doesn't implement SetVariable at runtime.
CVE-2024-26598:In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cache
There is a potential UAF scenario in the case of an LPI translation
cache hit racing with an operation that invalidates the cache, such
as a DISCARD ITS command. The root of the problem is that
vgic_its_check_cache() does not elevate the refcount on the vgic_irq
before dropping the lock that serializes refcount changes.
Have vgic_its_check_cache() raise the refcount on the returned vgic_irq
and add the corresponding decrement after queueing the interrupt.
CVE-2023-52448:In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dump
Syzkaller has reported a NULL pointer dereference when accessing
rgd-&gt;rd_rgl in gfs2_rgrp_dump().  This can happen when creating
rgd-&gt;rd_gl fails in read_rindex_entry().  Add a NULL pointer check in
gfs2_rgrp_dump() to prevent that.
CVE-2024-26595:In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error path
When calling mlxsw_sp_acl_tcam_region_destroy() from an error path after
failing to attach the region to an ACL group, we hit a NULL pointer
dereference upon 'region-&gt;group-&gt;tcam' [1].
Fix by retrieving the 'tcam' pointer using mlxsw_sp_acl_to_tcam().
[1]
BUG: kernel NULL pointer dereference, address: 0000000000000000
[...]
RIP: 0010:mlxsw_sp_acl_tcam_region_destroy+0xa0/0xd0
[...]
Call Trace:
 mlxsw_sp_acl_tcam_vchunk_get+0x88b/0xa20
 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
 mlxsw_sp_acl_rule_add+0x47/0x240
 mlxsw_sp_flower_replace+0x1a9/0x1d0
 tc_setup_cb_add+0xdc/0x1c0
 fl_hw_replace_filter+0x146/0x1f0
 fl_change+0xc17/0x1360
 tc_new_tfilter+0x472/0xb90
 rtnetlink_rcv_msg+0x313/0x3b0
 netlink_rcv_skb+0x58/0x100
 netlink_unicast+0x244/0x390
 netlink_sendmsg+0x1e4/0x440
 ____sys_sendmsg+0x164/0x260
 ___sys_sendmsg+0x9a/0xe0
 __sys_sendmsg+0x7a/0xc0
 do_syscall_64+0x40/0xe0
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CVE-2023-52436:In the Linux kernel, the following vulnerability has been resolved:
f2fs: explicitly null-terminate the xattr list
When setting an xattr, explicitly null-terminate the xattr list.  This
eliminates the fragile assumption that the unused xattr space is always
zeroed.
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.
CVE-2023-52438:In the Linux kernel, the following vulnerability has been resolved:
binder: fix use-after-free in shinker's callback
The mmap read lock is used during the shrinker's callback, which means
that using alloc-&gt;vma pointer isn't safe as it can race with munmap().
As of commit dd2283f2605e (&quot;mm: mmap: zap pages with read mmap_sem in
munmap&quot;) the mmap lock is downgraded after the vma has been isolated.
I was able to reproduce this issue by manually adding some delays and
triggering page reclaiming through the shrinker's debug sysfs. The
following KASAN report confirms the UAF:
  ==================================================================
  BUG: KASAN: slab-use-after-free in zap_page_range_single+0x470/0x4b8
  Read of size 8 at addr ffff356ed50e50f0 by task bash/478
  CPU: 1 PID: 478 Comm: bash Not tainted 6.6.0-rc5-00055-g1c8b86a3799f-dirty #70
  Hardware name: linux,dummy-virt (DT)
  Call trace:
   zap_page_range_single+0x470/0x4b8
   binder_alloc_free_page+0x608/0xadc
   __list_lru_walk_one+0x130/0x3b0
   list_lru_walk_node+0xc4/0x22c
   binder_shrink_scan+0x108/0x1dc
   shrinker_debugfs_scan_write+0x2b4/0x500
   full_proxy_write+0xd4/0x140
   vfs_write+0x1ac/0x758
   ksys_write+0xf0/0x1dc
   __arm64_sys_write+0x6c/0x9c
  Allocated by task 492:
   kmem_cache_alloc+0x130/0x368
   vm_area_alloc+0x2c/0x190
   mmap_region+0x258/0x18bc
   do_mmap+0x694/0xa60
   vm_mmap_pgoff+0x170/0x29c
   ksys_mmap_pgoff+0x290/0x3a0
   __arm64_sys_mmap+0xcc/0x144
  Freed by task 491:
   kmem_cache_free+0x17c/0x3c8
   vm_area_free_rcu_cb+0x74/0x98
   rcu_core+0xa38/0x26d4
   rcu_core_si+0x10/0x1c
   __do_softirq+0x2fc/0xd24
  Last potentially related work creation:
   __call_rcu_common.constprop.0+0x6c/0xba0
   call_rcu+0x10/0x1c
   vm_area_free+0x18/0x24
   remove_vma+0xe4/0x118
   do_vmi_align_munmap.isra.0+0x718/0xb5c
   do_vmi_munmap+0xdc/0x1fc
   __vm_munmap+0x10c/0x278
   __arm64_sys_munmap+0x58/0x7c
Fix this issue by performing instead a vma_lookup() which will fail to
find the vma that was isolated before the mmap lock downgrade. Note that
this option has better performance than upgrading to a mmap write lock
which would increase contention. Plus, mmap_write_trylock() has been
recently removed anyway.
CVE-2024-26583:In the Linux kernel, the following vulnerability has been resolved:
tls: fix race between async notify and socket close
The submitting thread (one which called recvmsg/sendmsg)
may exit as soon as the async crypto handler calls complete()
so any code past that point risks touching already freed data.
Try to avoid the locking and extra flags altogether.
Have the main thread hold an extra reference, this way
we can depend solely on the atomic ref counter for
synchronization.
Don't futz with reiniting the completion, either, we are now
tightly controlling when completion fires.
CVE-2023-52439:In the Linux kernel, the following vulnerability has been resolved:
uio: Fix use-after-free in uio_open
core-1				core-2
-------------------------------------------------------
uio_unregister_device		uio_open
				idev = idr_find()
device_unregister(&amp;idev-&gt;dev)
put_device(&amp;idev-&gt;dev)
uio_device_release
				get_device(&amp;idev-&gt;dev)
kfree(idev)
uio_free_minor(minor)
				uio_release
				put_device(&amp;idev-&gt;dev)
				kfree(idev)
-------------------------------------------------------
In the core-1 uio_unregister_device(), the device_unregister will kfree
idev when the idev-&gt;dev kobject ref is 1. But after core-1
device_unregister, put_device and before doing kfree, the core-2 may
get_device. Then:
1. After core-1 kfree idev, the core-2 will do use-after-free for idev.
2. When core-2 do uio_release and put_device, the idev will be double
   freed.
To address this issue, we can get idev atomic &amp; inc idev reference with
minor_lock.
CVE-2023-52522:In the Linux kernel, the following vulnerability has been resolved:
net: fix possible store tearing in neigh_periodic_work()
While looking at a related syzbot report involving neigh_periodic_work(),
I found that I forgot to add an annotation when deleting an
RCU protected item from a list.
Readers use rcu_deference(*np), we need to use either
rcu_assign_pointer() or WRITE_ONCE() on writer side
to prevent store tearing.
I use rcu_assign_pointer() to have lockdep support,
this was the choice made in neigh_flush_dev().
CVE-2023-52573:In the Linux kernel, the following vulnerability has been resolved:
net: rds: Fix possible NULL-pointer dereference
In rds_rdma_cm_event_handler_cmn() check, if conn pointer exists
before dereferencing it as rdma_set_service_type() argument
Found by Linux Verification Center (linuxtesting.org) with SVACE.
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.
This issue affects Linux kernel: v2.6.12-rc2.
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.
CVE-2023-52510:In the Linux kernel, the following vulnerability has been resolved:
ieee802154: ca8210: Fix a potential UAF in ca8210_probe
If of_clk_add_provider() fails in ca8210_register_ext_clock(),
it calls clk_unregister() to release priv-&gt;clk and returns an
error. However, the caller ca8210_probe() then calls ca8210_remove(),
where priv-&gt;clk is freed again in ca8210_unregister_ext_clock(). In
this case, a use-after-free may happen in the second time we call
clk_unregister().
Fix this by removing the first clk_unregister(). Also, priv-&gt;clk could
be an error code on failure of clk_register_fixed_rate(). Use
IS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().
CVE-2023-52458:In the Linux kernel, the following vulnerability has been resolved:
block: add check that partition length needs to be aligned with block size
Before calling add partition or resize partition, there is no check
on whether the length is aligned with the logical block size.
If the logical block size of the disk is larger than 512 bytes,
then the partition size maybe not the multiple of the logical block size,
and when the last sector is read, bio_truncate() will adjust the bio size,
resulting in an IO error if the size of the read command is smaller than
the logical block size.If integrity data is supported, this will also
result in a null pointer dereference when calling bio_integrity_free.
CVE-2021-47014:In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix wild memory access when clearing fragments
while testing re-assembly/re-fragmentation using act_ct, it's possible to
observe a crash like the following one:
 KASAN: maybe wild-memory-access in range [0x0001000000000448-0x000100000000044f]
 CPU: 50 PID: 0 Comm: swapper/50 Tainted: G S                5.12.0-rc7+ #424
 Hardware name: Dell Inc. PowerEdge R730/072T6D, BIOS 2.4.3 01/17/2017
 RIP: 0010:inet_frag_rbtree_purge+0x50/0xc0
 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
 RSP: 0018:ffff888c31449db8 EFLAGS: 00010203
 RAX: 0000200000000089 RBX: 000100000000040e RCX: ffffffff989eb960
 RDX: 0000000000000140 RSI: ffffffff97cfb977 RDI: 000100000000044e
 RBP: 0000000000000900 R08: 0000000000000000 R09: ffffed1186289350
 R10: 0000000000000003 R11: ffffed1186289350 R12: dffffc0000000000
 R13: 000100000000040e R14: 0000000000000000 R15: ffff888155e02160
 FS:  0000000000000000(0000) GS:ffff888c31440000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00005600cb70a5b8 CR3: 0000000a2c014005 CR4: 00000000003706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;IRQ&gt;
  inet_frag_destroy+0xa9/0x150
  call_timer_fn+0x2d/0x180
  run_timer_softirq+0x4fe/0xe70
  __do_softirq+0x197/0x5a0
  irq_exit_rcu+0x1de/0x200
  sysvec_apic_timer_interrupt+0x6b/0x80
  &lt;/IRQ&gt;
when act_ct temporarily stores an IP fragment, restoring the skb qdisc cb
results in putting random data in FRAG_CB(), and this causes those &quot;wild&quot;
memory accesses later, when the rbtree is purged. Never overwrite the skb
cb in case tcf_ct_handle_fragments() returns -EINPROGRESS.
CVE-2021-47036:In the Linux kernel, the following vulnerability has been resolved:
udp: skip L4 aggregation for UDP tunnel packets
If NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and there
are UDP tunnels available in the system, udp_gro_receive() could end-up
doing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) at
the outer UDP tunnel level for packets effectively carrying and UDP
tunnel header.
That could cause inner protocol corruption. If e.g. the relevant
packets carry a vxlan header, different vxlan ids will be ignored/
aggregated to the same GSO packet. Inner headers will be ignored, too,
so that e.g. TCP over vxlan push packets will be held in the GRO
engine till the next flush, etc.
Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if the
current packet could land in a UDP tunnel, and let udp_gro_receive()
do GRO via udp_sk(sk)-&gt;gro_receive.
The check implemented in this patch is broader than what is strictly
needed, as the existing UDP tunnel could be e.g. configured on top of
a different device: we could end-up skipping GRO at-all for some packets.
Anyhow, that is a very thin corner case and covering it will add quite
a bit of complexity.
v1 -&gt; v2:
 - hopefully clarify the commit message
CVE-2023-52566:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential use after free in nilfs_gccache_submit_read_data()
In nilfs_gccache_submit_read_data(), brelse(bh) is called to drop the
reference count of bh when the call to nilfs_dat_translate() fails.  If
the reference count hits 0 and its owner page gets unlocked, bh may be
freed.  However, bh-&gt;b_page is dereferenced to put the page after that,
which may result in a use-after-free bug.  This patch moves the release
operation after unlocking and putting the page.
NOTE: The function in question is only called in GC, and in combination
with current userland tools, address translation using DAT does not occur
in that function, so the code path that causes this issue will not be
executed.  However, it is possible to run that code path by intentionally
modifying the userland GC library or by calling the GC ioctl directly.
[konishi.ryusuke@gmail.com: NOTE added to the commit log]
CVE-2021-47028:In the Linux kernel, the following vulnerability has been resolved:
mt76: mt7915: fix txrate reporting
Properly check rate_info to fix unexpected reporting.
[ 1215.161863] Call trace:
[ 1215.164307]  cfg80211_calculate_bitrate+0x124/0x200 [cfg80211]
[ 1215.170139]  ieee80211s_update_metric+0x80/0xc0 [mac80211]
[ 1215.175624]  ieee80211_tx_status_ext+0x508/0x838 [mac80211]
[ 1215.181190]  mt7915_mcu_get_rx_rate+0x28c/0x8d0 [mt7915e]
[ 1215.186580]  mt7915_mac_tx_free+0x324/0x7c0 [mt7915e]
[ 1215.191623]  mt7915_queue_rx_skb+0xa8/0xd0 [mt7915e]
[ 1215.196582]  mt76_dma_cleanup+0x7b0/0x11d0 [mt76]
[ 1215.201276]  __napi_poll+0x38/0xf8
[ 1215.204668]  napi_workfn+0x40/0x80
[ 1215.208062]  process_one_work+0x1fc/0x390
[ 1215.212062]  worker_thread+0x48/0x4d0
[ 1215.215715]  kthread+0x120/0x128
[ 1215.218935]  ret_from_fork+0x10/0x1c
CVE-2023-52568:In the Linux kernel, the following vulnerability has been resolved:
x86/sgx: Resolves SECS reclaim vs. page fault for EAUG race
The SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for an
enclave and set secs.epc_page to NULL. The SECS page is used for EAUG
and ELDU in the SGX page fault handler. However, the NULL check for
secs.epc_page is only done for ELDU, not EAUG before being used.
Fix this by doing the same NULL check and reloading of the SECS page as
needed for both EAUG and ELDU.
The SECS page holds global enclave metadata. It can only be reclaimed
when there are no other enclave pages remaining. At that point,
virtually nothing can be done with the enclave until the SECS page is
paged back in.
An enclave can not run nor generate page faults without a resident SECS
page. But it is still possible for a #PF for a non-SECS page to race
with paging out the SECS page: when the last resident non-SECS page A
triggers a #PF in a non-resident page B, and then page A and the SECS
both are paged out before the #PF on B is handled.
Hitting this bug requires that race triggered with a #PF for EAUG.
Following is a trace when it happens.
BUG: kernel NULL pointer dereference, address: 0000000000000000
RIP: 0010:sgx_encl_eaug_page+0xc7/0x210
Call Trace:
 ? __kmem_cache_alloc_node+0x16a/0x440
 ? xa_load+0x6e/0xa0
 sgx_vma_fault+0x119/0x230
 __do_fault+0x36/0x140
 do_fault+0x12f/0x400
 __handle_mm_fault+0x728/0x1110
 handle_mm_fault+0x105/0x310
 do_user_addr_fault+0x1ee/0x750
 ? __this_cpu_preempt_check+0x13/0x20
 exc_page_fault+0x76/0x180
 asm_exc_page_fault+0x27/0x30
CVE-2023-52449:In the Linux kernel, the following vulnerability has been resolved:
mtd: Fix gluebi NULL pointer dereference caused by ftl notifier
If both ftl.ko and gluebi.ko are loaded, the notifier of ftl
triggers NULL pointer dereference when trying to access
‘gluebi-&gt;desc’ in gluebi_read().
ubi_gluebi_init
  ubi_register_volume_notifier
    ubi_enumerate_volumes
      ubi_notify_all
        gluebi_notify    nb-&gt;notifier_call()
          gluebi_create
            mtd_device_register
              mtd_device_parse_register
                add_mtd_device
                  blktrans_notify_add   not-&gt;add()
                    ftl_add_mtd         tr-&gt;add_mtd()
                      scan_header
                        mtd_read
                          mtd_read_oob
                            mtd_read_oob_std
                              gluebi_read   mtd-&gt;read()
                                gluebi-&gt;desc - NULL
Detailed reproduction information available at the Link [1],
In the normal case, obtain gluebi-&gt;desc in the gluebi_get_device(),
and access gluebi-&gt;desc in the gluebi_read(). However,
gluebi_get_device() is not executed in advance in the
ftl_add_mtd() process, which leads to NULL pointer dereference.
The solution for the gluebi module is to run jffs2 on the UBI
volume without considering working with ftl or mtdblock [2].
Therefore, this problem can be avoided by preventing gluebi from
creating the mtdblock device after creating mtd partition of the
type MTD_UBIVOLUME.
CVE-2023-52447:In the Linux kernel, the following vulnerability has been resolved:
bpf: Defer the free of inner map when necessary
When updating or deleting an inner map in map array or map htab, the map
may still be accessed by non-sleepable program or sleepable program.
However bpf_map_fd_put_ptr() decreases the ref-counter of the inner map
directly through bpf_map_put(), if the ref-counter is the last one
(which is true for most cases), the inner map will be freed by
ops-&gt;map_free() in a kworker. But for now, most .map_free() callbacks
don't use synchronize_rcu() or its variants to wait for the elapse of a
RCU grace period, so after the invocation of ops-&gt;map_free completes,
the bpf program which is accessing the inner map may incur
use-after-free problem.
Fix the free of inner map by invoking bpf_map_free_deferred() after both
one RCU grace period and one tasks trace RCU grace period if the inner
map has been removed from the outer map before. The deferment is
accomplished by using call_rcu() or call_rcu_tasks_trace() when
releasing the last ref-counter of bpf map. The newly-added rcu_head
field in bpf_map shares the same storage space with work field to
reduce the size of bpf_map.
CVE-2023-52452:In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix accesses to uninit stack slots
Privileged programs are supposed to be able to read uninitialized stack
memory (ever since 6715df8d5) but, before this patch, these accesses
were permitted inconsistently. In particular, accesses were permitted
above state-&gt;allocated_stack, but not below it. In other words, if the
stack was already &quot;large enough&quot;, the access was permitted, but
otherwise the access was rejected instead of being allowed to &quot;grow the
stack&quot;. This undesired rejection was happening in two places:
- in check_stack_slot_within_bounds()
- in check_stack_range_initialized()
This patch arranges for these accesses to be permitted. A bunch of tests
that were relying on the old rejection had to change; all of them were
changed to add also run unprivileged, in which case the old behavior
persists. One tests couldn't be updated - global_func16 - because it
can't run unprivileged for other reasons.
This patch also fixes the tracking of the stack size for variable-offset
reads. This second fix is bundled in the same commit as the first one
because they're inter-related. Before this patch, writes to the stack
using registers containing a variable offset (as opposed to registers
with fixed, known values) were not properly contributing to the
function's needed stack size. As a result, it was possible for a program
to verify, but then to attempt to read out-of-bounds data at runtime
because a too small stack had been allocated for it.
Each function tracks the size of the stack it needs in
bpf_subprog_info.stack_depth, which is maintained by
update_stack_depth(). For regular memory accesses, check_mem_access()
was calling update_state_depth() but it was passing in only the fixed
part of the offset register, ignoring the variable offset. This was
incorrect; the minimum possible value of that register should be used
instead.
This tracking is now fixed by centralizing the tracking of stack size in
grow_stack_state(), and by lifting the calls to grow_stack_state() to
check_stack_access_within_bounds() as suggested by Andrii. The code is
now simpler and more convincingly tracks the correct maximum stack size.
check_stack_range_initialized() can now rely on enough stack having been
allocated for the access; this helps with the fix for the first issue.
A few tests were changed to also check the stack depth computation. The
one that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.
CVE-2023-52451:In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries/memhp: Fix access beyond end of drmem array
dlpar_memory_remove_by_index() may access beyond the bounds of the
drmem lmb array when the LMB lookup fails to match an entry with the
given DRC index. When the search fails, the cursor is left pointing to
&amp;drmem_info-&gt;lmbs[drmem_info-&gt;n_lmbs], which is one element past the
last valid entry in the array. The debug message at the end of the
function then dereferences this pointer:
        pr_debug(&quot;Failed to hot-remove memory at %llx\n&quot;,
                 lmb-&gt;base_addr);
This was found by inspection and confirmed with KASAN:
  pseries-hotplug-mem: Attempting to hot-remove LMB, drc index 1234
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in dlpar_memory+0x298/0x1658
  Read of size 8 at addr c000000364e97fd0 by task bash/949
  dump_stack_lvl+0xa4/0xfc (unreliable)
  print_report+0x214/0x63c
  kasan_report+0x140/0x2e0
  __asan_load8+0xa8/0xe0
  dlpar_memory+0x298/0x1658
  handle_dlpar_errorlog+0x130/0x1d0
  dlpar_store+0x18c/0x3e0
  kobj_attr_store+0x68/0xa0
  sysfs_kf_write+0xc4/0x110
  kernfs_fop_write_iter+0x26c/0x390
  vfs_write+0x2d4/0x4e0
  ksys_write+0xac/0x1a0
  system_call_exception+0x268/0x530
  system_call_vectored_common+0x15c/0x2ec
  Allocated by task 1:
   kasan_save_stack+0x48/0x80
   kasan_set_track+0x34/0x50
   kasan_save_alloc_info+0x34/0x50
   __kasan_kmalloc+0xd0/0x120
   __kmalloc+0x8c/0x320
   kmalloc_array.constprop.0+0x48/0x5c
   drmem_init+0x2a0/0x41c
   do_one_initcall+0xe0/0x5c0
   kernel_init_freeable+0x4ec/0x5a0
   kernel_init+0x30/0x1e0
   ret_from_kernel_user_thread+0x14/0x1c
  The buggy address belongs to the object at c000000364e80000
   which belongs to the cache kmalloc-128k of size 131072
  The buggy address is located 0 bytes to the right of
   allocated 98256-byte region [c000000364e80000, c000000364e97fd0)
  ==================================================================
  pseries-hotplug-mem: Failed to hot-remove memory at 0
Log failed lookups with a separate message and dereference the
cursor only when it points to a valid entry.
CVE-2023-52583:In the Linux kernel, the following vulnerability has been resolved:
ceph: fix deadlock or deadcode of misusing dget()
The lock order is incorrect between denty and its parent, we should
always make sure that the parent get the lock first.
But since this deadcode is never used and the parent dir will always
be set from the callers, let's just remove it.
CVE-2023-52606:In the Linux kernel, the following vulnerability has been resolved:
powerpc/lib: Validate size for vector operations
Some of the fp/vmx code in sstep.c assume a certain maximum size for the
instructions being emulated. The size of those operations however is
determined separately in analyse_instr().
Add a check to validate the assumption on the maximum size of the
operations, so as to prevent any unintended kernel stack corruption.
CVE-2023-52486:In the Linux kernel, the following vulnerability has been resolved:
drm: Don't unref the same fb many times by mistake due to deadlock handling
If we get a deadlock after the fb lookup in drm_mode_page_flip_ioctl()
we proceed to unref the fb and then retry the whole thing from the top.
But we forget to reset the fb pointer back to NULL, and so if we then
get another error during the retry, before the fb lookup, we proceed
the unref the same fb again without having gotten another reference.
The end result is that the fb will (eventually) end up being freed
while it's still in use.
Reset fb to NULL once we've unreffed it to avoid doing it again
until we've done another fb lookup.
This turned out to be pretty easy to hit on a DG2 when doing async
flips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom I
saw that drm_closefb() simply got stuck in a busy loop while walking
the framebuffer list. Fortunately I was able to convince it to oops
instead, and from there it was easier to track down the culprit.
CVE-2021-46987:In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix deadlock when cloning inline extents and using qgroups
There are a few exceptional cases where cloning an inline extent needs to
copy the inline extent data into a page of the destination inode.
When this happens, we end up starting a transaction while having a dirty
page for the destination inode and while having the range locked in the
destination's inode iotree too. Because when reserving metadata space
for a transaction we may need to flush existing delalloc in case there is
not enough free space, we have a mechanism in place to prevent a deadlock,
which was introduced in commit 3d45f221ce627d (&quot;btrfs: fix deadlock when
cloning inline extent and low on free metadata space&quot;).
However when using qgroups, a transaction also reserves metadata qgroup
space, which can also result in flushing delalloc in case there is not
enough available space at the moment. When this happens we deadlock, since
flushing delalloc requires locking the file range in the inode's iotree
and the range was already locked at the very beginning of the clone
operation, before attempting to start the transaction.
When this issue happens, stack traces like the following are reported:
  [72747.556262] task:kworker/u81:9   state:D stack:    0 pid:  225 ppid:     2 flags:0x00004000
  [72747.556268] Workqueue: writeback wb_workfn (flush-btrfs-1142)
  [72747.556271] Call Trace:
  [72747.556273]  __schedule+0x296/0x760
  [72747.556277]  schedule+0x3c/0xa0
  [72747.556279]  io_schedule+0x12/0x40
  [72747.556284]  __lock_page+0x13c/0x280
  [72747.556287]  ? generic_file_readonly_mmap+0x70/0x70
  [72747.556325]  extent_write_cache_pages+0x22a/0x440 [btrfs]
  [72747.556331]  ? __set_page_dirty_nobuffers+0xe7/0x160
  [72747.556358]  ? set_extent_buffer_dirty+0x5e/0x80 [btrfs]
  [72747.556362]  ? update_group_capacity+0x25/0x210
  [72747.556366]  ? cpumask_next_and+0x1a/0x20
  [72747.556391]  extent_writepages+0x44/0xa0 [btrfs]
  [72747.556394]  do_writepages+0x41/0xd0
  [72747.556398]  __writeback_single_inode+0x39/0x2a0
  [72747.556403]  writeback_sb_inodes+0x1ea/0x440
  [72747.556407]  __writeback_inodes_wb+0x5f/0xc0
  [72747.556410]  wb_writeback+0x235/0x2b0
  [72747.556414]  ? get_nr_inodes+0x35/0x50
  [72747.556417]  wb_workfn+0x354/0x490
  [72747.556420]  ? newidle_balance+0x2c5/0x3e0
  [72747.556424]  process_one_work+0x1aa/0x340
  [72747.556426]  worker_thread+0x30/0x390
  [72747.556429]  ? create_worker+0x1a0/0x1a0
  [72747.556432]  kthread+0x116/0x130
  [72747.556435]  ? kthread_park+0x80/0x80
  [72747.556438]  ret_from_fork+0x1f/0x30
  [72747.566958] Workqueue: btrfs-flush_delalloc btrfs_work_helper [btrfs]
  [72747.566961] Call Trace:
  [72747.566964]  __schedule+0x296/0x760
  [72747.566968]  ? finish_wait+0x80/0x80
  [72747.566970]  schedule+0x3c/0xa0
  [72747.566995]  wait_extent_bit.constprop.68+0x13b/0x1c0 [btrfs]
  [72747.566999]  ? finish_wait+0x80/0x80
  [72747.567024]  lock_extent_bits+0x37/0x90 [btrfs]
  [72747.567047]  btrfs_invalidatepage+0x299/0x2c0 [btrfs]
  [72747.567051]  ? find_get_pages_range_tag+0x2cd/0x380
  [72747.567076]  __extent_writepage+0x203/0x320 [btrfs]
  [72747.567102]  extent_write_cache_pages+0x2bb/0x440 [btrfs]
  [72747.567106]  ? update_load_avg+0x7e/0x5f0
  [72747.567109]  ? enqueue_entity+0xf4/0x6f0
  [72747.567134]  extent_writepages+0x44/0xa0 [btrfs]
  [72747.567137]  ? enqueue_task_fair+0x93/0x6f0
  [72747.567140]  do_writepages+0x41/0xd0
  [72747.567144]  __filemap_fdatawrite_range+0xc7/0x100
  [72747.567167]  btrfs_run_delalloc_work+0x17/0x40 [btrfs]
  [72747.567195]  btrfs_work_helper+0xc2/0x300 [btrfs]
  [72747.567200]  process_one_work+0x1aa/0x340
  [72747.567202]  worker_thread+0x30/0x390
  [72747.567205]  ? create_worker+0x1a0/0x1a0
  [72747.567208]  kthread+0x116/0x130
  [72747.567211]  ? kthread_park+0x80/0x80
  [72747.567214]  ret_from_fork+0x1f/0x30
  [72747.569686] task:fsstress        state:D stack:    
---truncated---
CVE-2023-52507:In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: assert requested protocol is valid
The protocol is used in a bit mask to determine if the protocol is
supported. Assert the provided protocol is less than the maximum
defined so it doesn't potentially perform a shift-out-of-bounds and
provide a clearer error for undefined protocols vs unsupported ones.
CVE-2023-52515:In the Linux kernel, the following vulnerability has been resolved:
RDMA/srp: Do not call scsi_done() from srp_abort()
After scmd_eh_abort_handler() has called the SCSI LLD eh_abort_handler
callback, it performs one of the following actions:
* Call scsi_queue_insert().
* Call scsi_finish_command().
* Call scsi_eh_scmd_add().
Hence, SCSI abort handlers must not call scsi_done(). Otherwise all
the above actions would trigger a use-after-free. Hence remove the
scsi_done() call from srp_abort(). Keep the srp_free_req() call
before returning SUCCESS because we may not see the command again if
SUCCESS is returned.
CVE-2024-26586:In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix stack corruption
When tc filters are first added to a net device, the corresponding local
port gets bound to an ACL group in the device. The group contains a list
of ACLs. In turn, each ACL points to a different TCAM region where the
filters are stored. During forwarding, the ACLs are sequentially
evaluated until a match is found.
One reason to place filters in different regions is when they are added
with decreasing priorities and in an alternating order so that two
consecutive filters can never fit in the same region because of their
key usage.
In Spectrum-2 and newer ASICs the firmware started to report that the
maximum number of ACLs in a group is more than 16, but the layout of the
register that configures ACL groups (PAGT) was not updated to account
for that. It is therefore possible to hit stack corruption [1] in the
rare case where more than 16 ACLs in a group are required.
Fix by limiting the maximum ACL group size to the minimum between what
the firmware reports and the maximum ACLs that fit in the PAGT register.
Add a test case to make sure the machine does not crash when this
condition is hit.
[1]
Kernel panic - not syncing: stack-protector: Kernel stack is corrupted in: mlxsw_sp_acl_tcam_group_update+0x116/0x120
[...]
 dump_stack_lvl+0x36/0x50
 panic+0x305/0x330
 __stack_chk_fail+0x15/0x20
 mlxsw_sp_acl_tcam_group_update+0x116/0x120
 mlxsw_sp_acl_tcam_group_region_attach+0x69/0x110
 mlxsw_sp_acl_tcam_vchunk_get+0x492/0xa20
 mlxsw_sp_acl_tcam_ventry_add+0x25/0xe0
 mlxsw_sp_acl_rule_add+0x47/0x240
 mlxsw_sp_flower_replace+0x1a9/0x1d0
 tc_setup_cb_add+0xdc/0x1c0
 fl_hw_replace_filter+0x146/0x1f0
 fl_change+0xc17/0x1360
 tc_new_tfilter+0x472/0xb90
 rtnetlink_rcv_msg+0x313/0x3b0
 netlink_rcv_skb+0x58/0x100
 netlink_unicast+0x244/0x390
 netlink_sendmsg+0x1e4/0x440
 ____sys_sendmsg+0x164/0x260
 ___sys_sendmsg+0x9a/0xe0
 __sys_sendmsg+0x7a/0xc0
 do_syscall_64+0x40/0xe0
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CVE-2021-47076:In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Return CQE error if invalid lkey was supplied
RXE is missing update of WQE status in LOCAL_WRITE failures.  This caused
the following kernel panic if someone sent an atomic operation with an
explicitly wrong lkey.
[leonro@vm ~]$ mkt test
test_atomic_invalid_lkey (tests.test_atomic.AtomicTest) ...
 WARNING: CPU: 5 PID: 263 at drivers/infiniband/sw/rxe/rxe_comp.c:740 rxe_completer+0x1a6d/0x2e30 [rdma_rxe]
 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
 CPU: 5 PID: 263 Comm: python3 Not tainted 5.13.0-rc1+ #2936
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 RIP: 0010:rxe_completer+0x1a6d/0x2e30 [rdma_rxe]
 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
 RSP: 0018:ffff8880158af090 EFLAGS: 00010246
 RAX: 0000000000000000 RBX: ffff888016a78000 RCX: ffffffffa0cf1652
 RDX: 1ffff9200004b442 RSI: 0000000000000004 RDI: ffffc9000025a210
 RBP: dffffc0000000000 R08: 00000000ffffffea R09: ffff88801617740b
 R10: ffffed1002c2ee81 R11: 0000000000000007 R12: ffff88800f3b63e8
 R13: ffff888016a78008 R14: ffffc9000025a180 R15: 000000000000000c
 FS:  00007f88b622a740(0000) GS:ffff88806d540000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 00007f88b5a1fa10 CR3: 000000000d848004 CR4: 0000000000370ea0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  rxe_do_task+0x130/0x230 [rdma_rxe]
  rxe_rcv+0xb11/0x1df0 [rdma_rxe]
  rxe_loopback+0x157/0x1e0 [rdma_rxe]
  rxe_responder+0x5532/0x7620 [rdma_rxe]
  rxe_do_task+0x130/0x230 [rdma_rxe]
  rxe_rcv+0x9c8/0x1df0 [rdma_rxe]
  rxe_loopback+0x157/0x1e0 [rdma_rxe]
  rxe_requester+0x1efd/0x58c0 [rdma_rxe]
  rxe_do_task+0x130/0x230 [rdma_rxe]
  rxe_post_send+0x998/0x1860 [rdma_rxe]
  ib_uverbs_post_send+0xd5f/0x1220 [ib_uverbs]
  ib_uverbs_write+0x847/0xc80 [ib_uverbs]
  vfs_write+0x1c5/0x840
  ksys_write+0x176/0x1d0
  do_syscall_64+0x3f/0x80
  entry_SYSCALL_64_after_hwframe+0x44/0xae
CVE-2023-52524:In the Linux kernel, the following vulnerability has been resolved:
net: nfc: llcp: Add lock when modifying device list
The device list needs its associated lock held when modifying it, or the
list could become corrupted, as syzbot discovered.
CVE-2023-52527:In the Linux kernel, the following vulnerability has been resolved:
ipv4, ipv6: Fix handling of transhdrlen in __ip{,6}_append_data()
Including the transhdrlen in length is a problem when the packet is
partially filled (e.g. something like send(MSG_MORE) happened previously)
when appending to an IPv4 or IPv6 packet as we don't want to repeat the
transport header or account for it twice.  This can happen under some
circumstances, such as splicing into an L2TP socket.
The symptom observed is a warning in __ip6_append_data():
    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
that occurs when MSG_SPLICE_PAGES is used to append more data to an already
partially occupied skbuff.  The warning occurs when 'copy' is larger than
the amount of data in the message iterator.  This is because the requested
length includes the transport header length when it shouldn't.  This can be
triggered by, for example:
        sfd = socket(AF_INET6, SOCK_DGRAM, IPPROTO_L2TP);
        bind(sfd, ...); // ::1
        connect(sfd, ...); // ::1 port 7
        send(sfd, buffer, 4100, MSG_MORE);
        sendfile(sfd, dfd, NULL, 1024);
Fix this by only adding transhdrlen into the length if the write queue is
empty in l2tp_ip6_sendmsg(), analogously to how UDP does things.
l2tp_ip_sendmsg() looks like it won't suffer from this problem as it builds
the UDP packet itself.
CVE-2023-52445:In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix use after free on context disconnection
Upon module load, a kthread is created targeting the
pvr2_context_thread_func function, which may call pvr2_context_destroy
and thus call kfree() on the context object. However, that might happen
before the usb hub_event handler is able to notify the driver. This
patch adds a sanity check before the invalid read reported by syzbot,
within the context disconnection call stack.
CVE-2023-52500:In the Linux kernel, the following vulnerability has been resolved:
scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG command
Tags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freed
when we receive the response.
CVE-2023-52528:In the Linux kernel, the following vulnerability has been resolved:
net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_reg
syzbot reported the following uninit-value access issue:
=====================================================
BUG: KMSAN: uninit-value in smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
BUG: KMSAN: uninit-value in smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x21c/0x280 lib/dump_stack.c:118
 kmsan_report+0xf7/0x1e0 mm/kmsan/kmsan_report.c:121
 __msan_warning+0x58/0xa0 mm/kmsan/kmsan_instr.c:215
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:975 [inline]
 smsc75xx_bind+0x5c9/0x11e0 drivers/net/usb/smsc75xx.c:1482
 usbnet_probe+0x1152/0x3f90 drivers/net/usb/usbnet.c:1737
 usb_probe_interface+0xece/0x1550 drivers/usb/core/driver.c:374
 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
 usb_set_configuration+0x380f/0x3f10 drivers/usb/core/message.c:2032
 usb_generic_driver_probe+0x138/0x300 drivers/usb/core/generic.c:241
 usb_probe_device+0x311/0x490 drivers/usb/core/driver.c:272
 really_probe+0xf20/0x20b0 drivers/base/dd.c:529
 driver_probe_device+0x293/0x390 drivers/base/dd.c:701
 __device_attach_driver+0x63f/0x830 drivers/base/dd.c:807
 bus_for_each_drv+0x2ca/0x3f0 drivers/base/bus.c:431
 __device_attach+0x4e2/0x7f0 drivers/base/dd.c:873
 device_initial_probe+0x4a/0x60 drivers/base/dd.c:920
 bus_probe_device+0x177/0x3d0 drivers/base/bus.c:491
 device_add+0x3b0e/0x40d0 drivers/base/core.c:2680
 usb_new_device+0x1bd4/0x2a30 drivers/usb/core/hub.c:2554
 hub_port_connect drivers/usb/core/hub.c:5208 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5348 [inline]
 port_event drivers/usb/core/hub.c:5494 [inline]
 hub_event+0x5e7b/0x8a70 drivers/usb/core/hub.c:5576
 process_one_work+0x1688/0x2140 kernel/workqueue.c:2269
 worker_thread+0x10bc/0x2730 kernel/workqueue.c:2415
 kthread+0x551/0x590 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Local variable ----buf.i87@smsc75xx_bind created at:
 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
 smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
 __smsc75xx_read_reg drivers/net/usb/smsc75xx.c:83 [inline]
 smsc75xx_wait_ready drivers/net/usb/smsc75xx.c:968 [inline]
 smsc75xx_bind+0x485/0x11e0 drivers/net/usb/smsc75xx.c:1482
This issue is caused because usbnet_read_cmd() reads less bytes than requested
(zero byte in the reproducer). In this case, 'buf' is not properly filled.
This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() reads
less bytes than requested.
CVE-2023-52488:In the Linux kernel, the following vulnerability has been resolved:
serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFO
The SC16IS7XX IC supports a burst mode to access the FIFOs where the
initial register address is sent ($00), followed by all the FIFO data
without having to resend the register address each time. In this mode, the
IC doesn't increment the register address for each R/W byte.
The regmap_raw_read() and regmap_raw_write() are functions which can
perform IO over multiple registers. They are currently used to read/write
from/to the FIFO, and although they operate correctly in this burst mode on
the SPI bus, they would corrupt the regmap cache if it was not disabled
manually. The reason is that when the R/W size is more than 1 byte, these
functions assume that the register address is incremented and handle the
cache accordingly.
Convert FIFO R/W functions to use the regmap _noinc_ versions in order to
remove the manual cache control which was a workaround when using the
_raw_ versions. FIFO registers are properly declared as volatile so
cache will not be used/updated for FIFO accesses.
CVE-2023-52602:In the Linux kernel, the following vulnerability has been resolved:
jfs: fix slab-out-of-bounds Read in dtSearch
Currently while searching for current page in the sorted entry table
of the page there is a out of bound access. Added a bound check to fix
the error.
Dave:
Set return code to -EIO
CVE-2023-52603:In the Linux kernel, the following vulnerability has been resolved:
UBSAN: array-index-out-of-bounds in dtSplitRoot
Syzkaller reported the following issue:
oop0: detected capacity change from 0 to 32768
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9
index -2 is out of range for type 'struct dtslot [128]'
CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1b1/0x28e lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:151 [inline]
 __ubsan_handle_out_of_bounds+0xdb/0x130 lib/ubsan.c:283
 dtSplitRoot+0x8d8/0x1900 fs/jfs/jfs_dtree.c:1971
 dtSplitUp fs/jfs/jfs_dtree.c:985 [inline]
 dtInsert+0x1189/0x6b80 fs/jfs/jfs_dtree.c:863
 jfs_mkdir+0x757/0xb00 fs/jfs/namei.c:270
 vfs_mkdir+0x3b3/0x590 fs/namei.c:4013
 do_mkdirat+0x279/0x550 fs/namei.c:4038
 __do_sys_mkdirat fs/namei.c:4053 [inline]
 __se_sys_mkdirat fs/namei.c:4051 [inline]
 __x64_sys_mkdirat+0x85/0x90 fs/namei.c:4051
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3d/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fcdc0113fd9
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
RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9
RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003
RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0
R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000
R13: 0000000000000000 R14: 00083878000000f8 R15: 0000000000000000
 &lt;/TASK&gt;
The issue is caused when the value of fsi becomes less than -1.
The check to break the loop when fsi value becomes -1 is present
but syzbot was able to produce value less than -1 which cause the error.
This patch simply add the change for the values less than 0.
The patch is tested via syzbot.
CVE-2023-52593:In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()
Since 'ieee80211_beacon_get()' can return NULL, 'wfx_set_mfp_ap()'
should check the return value before examining skb data. So convert
the latter to return an appropriate error code and propagate it to
return from 'wfx_start_ap()' as well. Compile tested only.
CVE-2023-52604:In the Linux kernel, the following vulnerability has been resolved:
FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTree
Syzkaller reported the following issue:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6
index 196694 is out of range for type 's8[1365]' (aka 'signed char[1365]')
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:217 [inline]
 __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
 dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
 txUpdateMap+0x342/0x9e0
 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
 jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
 kthread+0x2d3/0x370 kernel/kthread.c:388
 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
 &lt;/TASK&gt;
================================================================================
Kernel panic - not syncing: UBSAN: panic_on_warn set ...
CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
 panic+0x30f/0x770 kernel/panic.c:340
 check_panic_on_warn+0x82/0xa0 kernel/panic.c:236
 ubsan_epilogue lib/ubsan.c:223 [inline]
 __ubsan_handle_out_of_bounds+0x13c/0x150 lib/ubsan.c:348
 dbAdjTree+0x474/0x4f0 fs/jfs/jfs_dmap.c:2867
 dbJoin+0x210/0x2d0 fs/jfs/jfs_dmap.c:2834
 dbFreeBits+0x4eb/0xda0 fs/jfs/jfs_dmap.c:2331
 dbFreeDmap fs/jfs/jfs_dmap.c:2080 [inline]
 dbFree+0x343/0x650 fs/jfs/jfs_dmap.c:402
 txFreeMap+0x798/0xd50 fs/jfs/jfs_txnmgr.c:2534
 txUpdateMap+0x342/0x9e0
 txLazyCommit fs/jfs/jfs_txnmgr.c:2664 [inline]
 jfs_lazycommit+0x47a/0xb70 fs/jfs/jfs_txnmgr.c:2732
 kthread+0x2d3/0x370 kernel/kthread.c:388
 ret_from_fork+0x48/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
 &lt;/TASK&gt;
Kernel Offset: disabled
Rebooting in 86400 seconds..
The issue is caused when the value of lp becomes greater than
CTLTREESIZE which is the max size of stree. Adding a simple check
solves this issue.
Dave:
As the function returns a void, good error handling
would require a more intrusive code reorganization, so I modified
Osama's patch at use WARN_ON_ONCE for lack of a cleaner option.
The patch is tested via syzbot.
CVE-2024-26627:In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Move scsi_host_busy() out of host lock for waking up EH handler
Inside scsi_eh_wakeup(), scsi_host_busy() is called &amp; checked with host
lock every time for deciding if error handler kthread needs to be waken up.
This can be too heavy in case of recovery, such as:
 - N hardware queues
 - queue depth is M for each hardware queue
 - each scsi_host_busy() iterates over (N * M) tag/requests
If recovery is triggered in case that all requests are in-flight, each
scsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is called
for the last in-flight request, scsi_host_busy() has been run for (N * M -
1) times, and request has been iterated for (N*M - 1) * (N * M) times.
If both N and M are big enough, hard lockup can be triggered on acquiring
host lock, and it is observed on mpi3mr(128 hw queues, queue depth 8169).
Fix the issue by calling scsi_host_busy() outside the host lock. We don't
need the host lock for getting busy count because host the lock never
covers that.
[mkp: Drop unnecessary 'busy' variables pointed out by Bart]
CVE-2023-52494:In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: Add alignment check for event ring read pointer
Though we do check the event ring read pointer by &quot;is_valid_ring_ptr&quot;
to make sure it is in the buffer range, but there is another risk the
pointer may be not aligned.  Since we are expecting event ring elements
are 128 bits(struct mhi_ring_element) aligned, an unaligned read pointer
could lead to multiple issues like DoS or ring buffer memory corruption.
So add a alignment check for event ring read pointer.
CVE-2024-26624:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-26625:In the Linux kernel, the following vulnerability has been resolved:
llc: call sock_orphan() at release time
syzbot reported an interesting trace [1] caused by a stale sk-&gt;sk_wq
pointer in a closed llc socket.
In commit ff7b11aa481f (&quot;net: socket: set sock-&gt;sk to NULL after
calling proto_ops::release()&quot;) Eric Biggers hinted that some protocols
are missing a sock_orphan(), we need to perform a full audit.
In net-next, I plan to clear sock-&gt;sk from sock_orphan() and
amend Eric patch to add a warning.
[1]
 BUG: KASAN: slab-use-after-free in list_empty include/linux/list.h:373 [inline]
 BUG: KASAN: slab-use-after-free in waitqueue_active include/linux/wait.h:127 [inline]
 BUG: KASAN: slab-use-after-free in sock_def_write_space_wfree net/core/sock.c:3384 [inline]
 BUG: KASAN: slab-use-after-free in sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27
CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0xc4/0x620 mm/kasan/report.c:488
  kasan_report+0xda/0x110 mm/kasan/report.c:601
  list_empty include/linux/list.h:373 [inline]
  waitqueue_active include/linux/wait.h:127 [inline]
  sock_def_write_space_wfree net/core/sock.c:3384 [inline]
  sock_wfree+0x9a8/0x9d0 net/core/sock.c:2468
  skb_release_head_state+0xa3/0x2b0 net/core/skbuff.c:1080
  skb_release_all net/core/skbuff.c:1092 [inline]
  napi_consume_skb+0x119/0x2b0 net/core/skbuff.c:1404
  e1000_unmap_and_free_tx_resource+0x144/0x200 drivers/net/ethernet/intel/e1000/e1000_main.c:1970
  e1000_clean_tx_irq drivers/net/ethernet/intel/e1000/e1000_main.c:3860 [inline]
  e1000_clean+0x4a1/0x26e0 drivers/net/ethernet/intel/e1000/e1000_main.c:3801
  __napi_poll.constprop.0+0xb4/0x540 net/core/dev.c:6576
  napi_poll net/core/dev.c:6645 [inline]
  net_rx_action+0x956/0xe90 net/core/dev.c:6778
  __do_softirq+0x21a/0x8de kernel/softirq.c:553
  run_ksoftirqd kernel/softirq.c:921 [inline]
  run_ksoftirqd+0x31/0x60 kernel/softirq.c:913
  smpboot_thread_fn+0x660/0xa10 kernel/smpboot.c:164
  kthread+0x2c6/0x3a0 kernel/kthread.c:388
  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
  ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:242
 &lt;/TASK&gt;
Allocated by task 5167:
  kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
  kasan_save_track+0x14/0x30 mm/kasan/common.c:68
  unpoison_slab_object mm/kasan/common.c:314 [inline]
  __kasan_slab_alloc+0x81/0x90 mm/kasan/common.c:340
  kasan_slab_alloc include/linux/kasan.h:201 [inline]
  slab_post_alloc_hook mm/slub.c:3813 [inline]
  slab_alloc_node mm/slub.c:3860 [inline]
  kmem_cache_alloc_lru+0x142/0x6f0 mm/slub.c:3879
  alloc_inode_sb include/linux/fs.h:3019 [inline]
  sock_alloc_inode+0x25/0x1c0 net/socket.c:308
  alloc_inode+0x5d/0x220 fs/inode.c:260
  new_inode_pseudo+0x16/0x80 fs/inode.c:1005
  sock_alloc+0x40/0x270 net/socket.c:634
  __sock_create+0xbc/0x800 net/socket.c:1535
  sock_create net/socket.c:1622 [inline]
  __sys_socket_create net/socket.c:1659 [inline]
  __sys_socket+0x14c/0x260 net/socket.c:1706
  __do_sys_socket net/socket.c:1720 [inline]
  __se_sys_socket net/socket.c:1718 [inline]
  __x64_sys_socket+0x72/0xb0 net/socket.c:1718
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xd3/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Freed by task 0:
  kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
  kasan_save_track+0x14/0x30 mm/kasan/common.c:68
  kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
  poison_slab_object mm/kasan/common.c:241 [inline]
  __kasan_slab_free+0x121/0x1b0 mm/kasan/common.c:257
  kasan_slab_free include/linux/kasan.h:184 [inline]
  slab_free_hook mm/slub.c:2121 [inlin
---truncated---
CVE-2023-52502:In the Linux kernel, the following vulnerability has been resolved:
net: nfc: fix races in nfc_llcp_sock_get() and nfc_llcp_sock_get_sn()
Sili Luo reported a race in nfc_llcp_sock_get(), leading to UAF.
Getting a reference on the socket found in a lookup while
holding a lock should happen before releasing the lock.
nfc_llcp_sock_get_sn() has a similar problem.
Finally nfc_llcp_recv_snl() needs to make sure the socket
found by nfc_llcp_sock_from_sn() does not disappear.
CVE-2024-26622:In the Linux kernel, the following vulnerability has been resolved:
tomoyo: fix UAF write bug in tomoyo_write_control()
Since tomoyo_write_control() updates head-&gt;write_buf when write()
of long lines is requested, we need to fetch head-&gt;write_buf after
head-&gt;io_sem is held.  Otherwise, concurrent write() requests can
cause use-after-free-write and double-free problems.
CVE-2023-52599:In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diNewExt
[Syz report]
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_imap.c:2360:2
index -878706688 is out of range for type 'struct iagctl[128]'
CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x1e7/0x2d0 lib/dump_stack.c:106
 ubsan_epilogue lib/ubsan.c:217 [inline]
 __ubsan_handle_out_of_bounds+0x11c/0x150 lib/ubsan.c:348
 diNewExt+0x3cf3/0x4000 fs/jfs/jfs_imap.c:2360
 diAllocExt fs/jfs/jfs_imap.c:1949 [inline]
 diAllocAG+0xbe8/0x1e50 fs/jfs/jfs_imap.c:1666
 diAlloc+0x1d3/0x1760 fs/jfs/jfs_imap.c:1587
 ialloc+0x8f/0x900 fs/jfs/jfs_inode.c:56
 jfs_mkdir+0x1c5/0xb90 fs/jfs/namei.c:225
 vfs_mkdir+0x2f1/0x4b0 fs/namei.c:4106
 do_mkdirat+0x264/0x3a0 fs/namei.c:4129
 __do_sys_mkdir fs/namei.c:4149 [inline]
 __se_sys_mkdir fs/namei.c:4147 [inline]
 __x64_sys_mkdir+0x6e/0x80 fs/namei.c:4147
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x45/0x110 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
RIP: 0033:0x7fcb7e6a0b57
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
RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053
RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57
RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140
RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
[Analysis]
When the agstart is too large, it can cause agno overflow.
[Fix]
After obtaining agno, if the value is invalid, exit the subsequent process.
Modified the test from agno &gt; MAXAG to agno &gt;= MAXAG based on linux-next
report by kernel test robot (Dan Carpenter).
CVE-2023-52600:In the Linux kernel, the following vulnerability has been resolved:
jfs: fix uaf in jfs_evict_inode
When the execution of diMount(ipimap) fails, the object ipimap that has been
released may be accessed in diFreeSpecial(). Asynchronous ipimap release occurs
when rcu_core() calls jfs_free_node().
Therefore, when diMount(ipimap) fails, sbi-&gt;ipimap should not be initialized as
ipimap.
CVE-2023-52622:In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid online resizing failures due to oversized flex bg
When we online resize an ext4 filesystem with a oversized flexbg_size,
     mkfs.ext4 -F -G 67108864 $dev -b 4096 100M
     mount $dev $dir
     resize2fs $dev 16G
the following WARN_ON is triggered:
==================================================================
WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550
Modules linked in: sg(E)
CPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ #314
RIP: 0010:__alloc_pages+0x411/0x550
Call Trace:
 &lt;TASK&gt;
 __kmalloc_large_node+0xa2/0x200
 __kmalloc+0x16e/0x290
 ext4_resize_fs+0x481/0xd80
 __ext4_ioctl+0x1616/0x1d90
 ext4_ioctl+0x12/0x20
 __x64_sys_ioctl+0xf0/0x150
 do_syscall_64+0x3b/0x90
==================================================================
This is because flexbg_size is too large and the size of the new_group_data
array to be allocated exceeds MAX_ORDER. Currently, the minimum value of
MAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the corresponding
maximum number of groups that can be allocated is:
 (PAGE_SIZE &lt;&lt; MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845
And the value that is down-aligned to the power of 2 is 16384. Therefore,
this value is defined as MAX_RESIZE_BG, and the number of groups added
each time does not exceed this value during resizing, and is added multiple
times to complete the online resizing. The difference is that the metadata
in a flex_bg may be more dispersed.
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.
CVE-2021-47094:In the Linux kernel, the following vulnerability has been resolved:
KVM: x86/mmu: Don't advance iterator after restart due to yielding
After dropping mmu_lock in the TDP MMU, restart the iterator during
tdp_iter_next() and do not advance the iterator.  Advancing the iterator
results in skipping the top-level SPTE and all its children, which is
fatal if any of the skipped SPTEs were not visited before yielding.
When zapping all SPTEs, i.e. when min_level == root_level, restarting the
iter and then invoking tdp_iter_next() is always fatal if the current gfn
has as a valid SPTE, as advancing the iterator results in try_step_side()
skipping the current gfn, which wasn't visited before yielding.
Sprinkle WARNs on iter-&gt;yielded being true in various helpers that are
often used in conjunction with yielding, and tag the helper with
__must_check to reduce the probabily of improper usage.
Failing to zap a top-level SPTE manifests in one of two ways.  If a valid
SPTE is skipped by both kvm_tdp_mmu_zap_all() and kvm_tdp_mmu_put_root(),
the shadow page will be leaked and KVM will WARN accordingly.
  WARNING: CPU: 1 PID: 3509 at arch/x86/kvm/mmu/tdp_mmu.c:46 [kvm]
  RIP: 0010:kvm_mmu_uninit_tdp_mmu+0x3e/0x50 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_arch_destroy_vm+0x130/0x1b0 [kvm]
   kvm_destroy_vm+0x162/0x2a0 [kvm]
   kvm_vcpu_release+0x34/0x60 [kvm]
   __fput+0x82/0x240
   task_work_run+0x5c/0x90
   do_exit+0x364/0xa10
   ? futex_unqueue+0x38/0x60
   do_group_exit+0x33/0xa0
   get_signal+0x155/0x850
   arch_do_signal_or_restart+0xed/0x750
   exit_to_user_mode_prepare+0xc5/0x120
   syscall_exit_to_user_mode+0x1d/0x40
   do_syscall_64+0x48/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
If kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped by
kvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form of
marking a struct page as dirty/accessed after it has been put back on the
free list.  This directly triggers a WARN due to encountering a page with
page_count() == 0, but it can also lead to data corruption and additional
errors in the kernel.
  WARNING: CPU: 7 PID: 1995658 at arch/x86/kvm/../../../virt/kvm/kvm_main.c:171
  RIP: 0010:kvm_is_zone_device_pfn.part.0+0x9e/0xd0 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_set_pfn_dirty+0x120/0x1d0 [kvm]
   __handle_changed_spte+0x92e/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   __handle_changed_spte+0x63c/0xca0 [kvm]
   zap_gfn_range+0x549/0x620 [kvm]
   kvm_tdp_mmu_put_root+0x1b6/0x270 [kvm]
   mmu_free_root_page+0x219/0x2c0 [kvm]
   kvm_mmu_free_roots+0x1b4/0x4e0 [kvm]
   kvm_mmu_unload+0x1c/0xa0 [kvm]
   kvm_arch_destroy_vm+0x1f2/0x5c0 [kvm]
   kvm_put_kvm+0x3b1/0x8b0 [kvm]
   kvm_vcpu_release+0x4e/0x70 [kvm]
   __fput+0x1f7/0x8c0
   task_work_run+0xf8/0x1a0
   do_exit+0x97b/0x2230
   do_group_exit+0xda/0x2a0
   get_signal+0x3be/0x1e50
   arch_do_signal_or_restart+0x244/0x17f0
   exit_to_user_mode_prepare+0xcb/0x120
   syscall_exit_to_user_mode+0x1d/0x40
   do_syscall_64+0x4d/0x90
   entry_SYSCALL_64_after_hwframe+0x44/0xae
Note, the underlying bug existed even before commit 1af4a96025b3 (&quot;KVM:
x86/mmu: Yield in TDU MMU iter even if no SPTES changed&quot;) moved calls to
tdp_mmu_iter_cond_resched() to the beginning of loops, as KVM could still
incorrectly advance past a top-level entry when yielding on a lower-level
entry.  But with respect to leaking shadow pages, the bug was introduced
by yielding before processing the current gfn.
Alternatively, tdp_mmu_iter_cond_resched() could simply fall through, or
callers could jump to their &quot;retry&quot; label.  The downside of that approach
is that tdp_mmu_iter_cond_resched() _must_ be called before anything else
in the loop, and there's no easy way to enfornce that requirement.
Ideally, KVM would handling the cond_resched() fully within the iterator
macro (the code is actually quite clean) and avoid this entire class of
bugs, but that is extremely difficult do wh
---truncated---
CVE-2023-52601:In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in dbAdjTree
Currently there is a bound check missing in the dbAdjTree while
accessing the dmt_stree. To add the required check added the bool is_ctl
which is required to determine the size as suggest in the following
commit.
https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/
CVE-2021-46926:In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: intel-sdw-acpi: harden detection of controller
The existing code currently sets a pointer to an ACPI handle before
checking that it's actually a SoundWire controller. This can lead to
issues where the graph walk continues and eventually fails, but the
pointer was set already.
This patch changes the logic so that the information provided to
the caller is set when a controller is found.
CVE-2023-52479:In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix uaf in smb20_oplock_break_ack
drop reference after use opinfo.
CVE-2023-52484:In the Linux kernel, the following vulnerability has been resolved:
iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_range
When running an SVA case, the following soft lockup is triggered:
--------------------------------------------------------------------
watchdog: BUG: soft lockup - CPU#244 stuck for 26s!
pstate: 83400009 (Nzcv daif +PAN -UAO +TCO +DIT -SSBS BTYPE=--)
pc : arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50
sp : ffff8000d83ef290
x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000
x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000
x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0
x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0
x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bc
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfa
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000a
x2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001
Call trace:
 arm_smmu_cmdq_issue_cmdlist+0x178/0xa50
 __arm_smmu_tlb_inv_range+0x118/0x254
 arm_smmu_tlb_inv_range_asid+0x6c/0x130
 arm_smmu_mm_invalidate_range+0xa0/0xa4
 __mmu_notifier_invalidate_range_end+0x88/0x120
 unmap_vmas+0x194/0x1e0
 unmap_region+0xb4/0x144
 do_mas_align_munmap+0x290/0x490
 do_mas_munmap+0xbc/0x124
 __vm_munmap+0xa8/0x19c
 __arm64_sys_munmap+0x28/0x50
 invoke_syscall+0x78/0x11c
 el0_svc_common.constprop.0+0x58/0x1c0
 do_el0_svc+0x34/0x60
 el0_svc+0x2c/0xd4
 el0t_64_sync_handler+0x114/0x140
 el0t_64_sync+0x1a4/0x1a8
--------------------------------------------------------------------
Note that since 6.6-rc1 the arm_smmu_mm_invalidate_range above is renamed
to &quot;arm_smmu_mm_arch_invalidate_secondary_tlbs&quot;, yet the problem remains.
The commit 06ff87bae8d3 (&quot;arm64: mm: remove unused functions and variable
protoypes&quot;) fixed a similar lockup on the CPU MMU side. Yet, it can occur
to SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is called
typically next to MMU tlb flush function, e.g.
	tlb_flush_mmu_tlbonly {
		tlb_flush {
			__flush_tlb_range {
				// check MAX_TLBI_OPS
			}
		}
		mmu_notifier_arch_invalidate_secondary_tlbs {
			arm_smmu_mm_arch_invalidate_secondary_tlbs {
				// does not check MAX_TLBI_OPS
			}
		}
	}
Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in an
SVA case SMMU uses the CPU page table, so it makes sense to align with the
tlbflush code. Then, replace per-page TLBI commands with a single per-asid
TLBI command, if the request size hits this threshold.
CVE-2024-26593:In the Linux kernel, the following vulnerability has been resolved:
i2c: i801: Fix block process call transactions
According to the Intel datasheets, software must reset the block
buffer index twice for block process call transactions: once before
writing the outgoing data to the buffer, and once again before
reading the incoming data from the buffer.
The driver is currently missing the second reset, causing the wrong
portion of the block buffer to be read.
CVE-2024-26788:In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fsl-qdma: init irq after reg initialization
Initialize the qDMA irqs after the registers are configured so that
interrupts that may have been pending from a primary kernel don't get
processed by the irq handler before it is ready to and cause panic with
the following trace:
  Call trace:
   fsl_qdma_queue_handler+0xf8/0x3e8
   __handle_irq_event_percpu+0x78/0x2b0
   handle_irq_event_percpu+0x1c/0x68
   handle_irq_event+0x44/0x78
   handle_fasteoi_irq+0xc8/0x178
   generic_handle_irq+0x24/0x38
   __handle_domain_irq+0x90/0x100
   gic_handle_irq+0x5c/0xb8
   el1_irq+0xb8/0x180
   _raw_spin_unlock_irqrestore+0x14/0x40
   __setup_irq+0x4bc/0x798
   request_threaded_irq+0xd8/0x190
   devm_request_threaded_irq+0x74/0xe8
   fsl_qdma_probe+0x4d4/0xca8
   platform_drv_probe+0x50/0xa0
   really_probe+0xe0/0x3f8
   driver_probe_device+0x64/0x130
   device_driver_attach+0x6c/0x78
   __driver_attach+0xbc/0x158
   bus_for_each_dev+0x5c/0x98
   driver_attach+0x20/0x28
   bus_add_driver+0x158/0x220
   driver_register+0x60/0x110
   __platform_driver_register+0x44/0x50
   fsl_qdma_driver_init+0x18/0x20
   do_one_initcall+0x48/0x258
   kernel_init_freeable+0x1a4/0x23c
   kernel_init+0x10/0xf8
   ret_from_fork+0x10/0x18
CVE-2024-26607:In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: sii902x: Fix probing race issue
A null pointer dereference crash has been observed rarely on TI
platforms using sii9022 bridge:
[   53.271356]  sii902x_get_edid+0x34/0x70 [sii902x]
[   53.276066]  sii902x_bridge_get_edid+0x14/0x20 [sii902x]
[   53.281381]  drm_bridge_get_edid+0x20/0x34 [drm]
[   53.286305]  drm_bridge_connector_get_modes+0x8c/0xcc [drm_kms_helper]
[   53.292955]  drm_helper_probe_single_connector_modes+0x190/0x538 [drm_kms_helper]
[   53.300510]  drm_client_modeset_probe+0x1f0/0xbd4 [drm]
[   53.305958]  __drm_fb_helper_initial_config_and_unlock+0x50/0x510 [drm_kms_helper]
[   53.313611]  drm_fb_helper_initial_config+0x48/0x58 [drm_kms_helper]
[   53.320039]  drm_fbdev_dma_client_hotplug+0x84/0xd4 [drm_dma_helper]
[   53.326401]  drm_client_register+0x5c/0xa0 [drm]
[   53.331216]  drm_fbdev_dma_setup+0xc8/0x13c [drm_dma_helper]
[   53.336881]  tidss_probe+0x128/0x264 [tidss]
[   53.341174]  platform_probe+0x68/0xc4
[   53.344841]  really_probe+0x188/0x3c4
[   53.348501]  __driver_probe_device+0x7c/0x16c
[   53.352854]  driver_probe_device+0x3c/0x10c
[   53.357033]  __device_attach_driver+0xbc/0x158
[   53.361472]  bus_for_each_drv+0x88/0xe8
[   53.365303]  __device_attach+0xa0/0x1b4
[   53.369135]  device_initial_probe+0x14/0x20
[   53.373314]  bus_probe_device+0xb0/0xb4
[   53.377145]  deferred_probe_work_func+0xcc/0x124
[   53.381757]  process_one_work+0x1f0/0x518
[   53.385770]  worker_thread+0x1e8/0x3dc
[   53.389519]  kthread+0x11c/0x120
[   53.392750]  ret_from_fork+0x10/0x20
The issue here is as follows:
- tidss probes, but is deferred as sii902x is still missing.
- sii902x starts probing and enters sii902x_init().
- sii902x calls drm_bridge_add(). Now the sii902x bridge is ready from
  DRM's perspective.
- sii902x calls sii902x_audio_codec_init() and
  platform_device_register_data()
- The registration of the audio platform device causes probing of the
  deferred devices.
- tidss probes, which eventually causes sii902x_bridge_get_edid() to be
  called.
- sii902x_bridge_get_edid() tries to use the i2c to read the edid.
  However, the sii902x driver has not set up the i2c part yet, leading
  to the crash.
Fix this by moving the drm_bridge_add() to the end of the
sii902x_init(), which is also at the very end of sii902x_probe().
CVE-2024-26773:In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocating blocks from corrupted group in ext4_mb_try_best_found()
Determine if the group block bitmap is corrupted before using ac_b_ex in
ext4_mb_try_best_found() to avoid allocating blocks from a group with a
corrupted block bitmap in the following concurrency and making the
situation worse.
ext4_mb_regular_allocator
  ext4_lock_group(sb, group)
  ext4_mb_good_group
   // check if the group bbitmap is corrupted
  ext4_mb_complex_scan_group
   // Scan group gets ac_b_ex but doesn't use it
  ext4_unlock_group(sb, group)
                           ext4_mark_group_bitmap_corrupted(group)
                           // The block bitmap was corrupted during
                           // the group unlock gap.
  ext4_mb_try_best_found
    ext4_lock_group(ac-&gt;ac_sb, group)
    ext4_mb_use_best_found
      mb_mark_used
      // Allocating blocks in block bitmap corrupted group
CVE-2023-52469:In the Linux kernel, the following vulnerability has been resolved:
drivers/amd/pm: fix a use-after-free in kv_parse_power_table
When ps allocated by kzalloc equals to NULL, kv_parse_power_table
frees adev-&gt;pm.dpm.ps that allocated before. However, after the control
flow goes through the following call chains:
kv_parse_power_table
  |-&gt; kv_dpm_init
        |-&gt; kv_dpm_sw_init
	      |-&gt; kv_dpm_fini
The adev-&gt;pm.dpm.ps is used in the for loop of kv_dpm_fini after its
first free in kv_parse_power_table and causes a use-after-free bug.
CVE-2023-52475:In the Linux kernel, the following vulnerability has been resolved:
Input: powermate - fix use-after-free in powermate_config_complete
syzbot has found a use-after-free bug [1] in the powermate driver. This
happens when the device is disconnected, which leads to a memory free from
the powermate_device struct.  When an asynchronous control message
completes after the kfree and its callback is invoked, the lock does not
exist anymore and hence the bug.
Use usb_kill_urb() on pm-&gt;config to cancel any in-progress requests upon
device disconnection.
[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e
CVE-2024-26600:In the Linux kernel, the following vulnerability has been resolved:
phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRP
If the external phy working together with phy-omap-usb2 does not implement
send_srp(), we may still attempt to call it. This can happen on an idle
Ethernet gadget triggering a wakeup for example:
configfs-gadget.g1 gadget.0: ECM Suspend
configfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup
...
Unable to handle kernel NULL pointer dereference at virtual address
00000000 when execute
...
PC is at 0x0
LR is at musb_gadget_wakeup+0x1d4/0x254 [musb_hdrc]
...
musb_gadget_wakeup [musb_hdrc] from usb_gadget_wakeup+0x1c/0x3c [udc_core]
usb_gadget_wakeup [udc_core] from eth_start_xmit+0x3b0/0x3d4 [u_ether]
eth_start_xmit [u_ether] from dev_hard_start_xmit+0x94/0x24c
dev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4
sch_direct_xmit from __dev_queue_xmit+0x334/0xd88
__dev_queue_xmit from arp_solicit+0xf0/0x268
arp_solicit from neigh_probe+0x54/0x7c
neigh_probe from __neigh_event_send+0x22c/0x47c
__neigh_event_send from neigh_resolve_output+0x14c/0x1c0
neigh_resolve_output from ip_finish_output2+0x1c8/0x628
ip_finish_output2 from ip_send_skb+0x40/0xd8
ip_send_skb from udp_send_skb+0x124/0x340
udp_send_skb from udp_sendmsg+0x780/0x984
udp_sendmsg from __sys_sendto+0xd8/0x158
__sys_sendto from ret_fast_syscall+0x0/0x58
Let's fix the issue by checking for send_srp() and set_vbus() before
calling them. For USB peripheral only cases these both could be NULL.
CVE-2021-47037:In the Linux kernel, the following vulnerability has been resolved:
ASoC: q6afe-clocks: fix reprobing of the driver
Q6afe-clocks driver can get reprobed. For example if the APR services
are restarted after the firmware crash. However currently Q6afe-clocks
driver will oops because hw.init will get cleared during first _probe
call. Rewrite the driver to fill the clock data at runtime rather than
using big static array of clocks.
CVE-2023-52456:In the Linux kernel, the following vulnerability has been resolved:
serial: imx: fix tx statemachine deadlock
When using the serial port as RS485 port, the tx statemachine is used to
control the RTS pin to drive the RS485 transceiver TX_EN pin. When the
TTY port is closed in the middle of a transmission (for instance during
userland application crash), imx_uart_shutdown disables the interface
and disables the Transmission Complete interrupt. afer that,
imx_uart_stop_tx bails on an incomplete transmission, to be retriggered
by the TC interrupt. This interrupt is disabled and therefore the tx
statemachine never transitions out of SEND. The statemachine is in
deadlock now, and the TX_EN remains low, making the interface useless.
imx_uart_stop_tx now checks for incomplete transmission AND whether TC
interrupts are enabled before bailing to be retriggered. This makes sure
the state machine handling is reached, and is properly set to
WAIT_AFTER_SEND.
CVE-2024-26696:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix hang in nilfs_lookup_dirty_data_buffers()
Syzbot reported a hang issue in migrate_pages_batch() called by mbind()
and nilfs_lookup_dirty_data_buffers() called in the log writer of nilfs2.
While migrate_pages_batch() locks a folio and waits for the writeback to
complete, the log writer thread that should bring the writeback to
completion picks up the folio being written back in
nilfs_lookup_dirty_data_buffers() that it calls for subsequent log
creation and was trying to lock the folio.  Thus causing a deadlock.
In the first place, it is unexpected that folios/pages in the middle of
writeback will be updated and become dirty.  Nilfs2 adds a checksum to
verify the validity of the log being written and uses it for recovery at
mount, so data changes during writeback are suppressed.  Since this is
broken, an unclean shutdown could potentially cause recovery to fail.
Investigation revealed that the root cause is that the wait for writeback
completion in nilfs_page_mkwrite() is conditional, and if the backing
device does not require stable writes, data may be modified without
waiting.
Fix these issues by making nilfs_page_mkwrite() wait for writeback to
finish regardless of the stable write requirement of the backing device.
CVE-2023-52467:In the Linux kernel, the following vulnerability has been resolved:
mfd: syscon: Fix null pointer dereference in of_syscon_register()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
CVE-2024-26608:In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix global oob in ksmbd_nl_policy
Similar to a reported issue (check the commit b33fb5b801c6 (&quot;net:
qualcomm: rmnet: fix global oob in rmnet_policy&quot;), my local fuzzer finds
another global out-of-bounds read for policy ksmbd_nl_policy. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810
CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G                 N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x172/0x475 mm/kasan/report.c:395
 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
 validate_nla lib/nlattr.c:386 [inline]
 __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
 __nla_parse+0x3e/0x50 lib/nlattr.c:697
 __nlmsg_parse include/net/netlink.h:748 [inline]
 genl_family_rcv_msg_attrs_parse.constprop.0+0x1b0/0x290 net/netlink/genetlink.c:565
 genl_family_rcv_msg_doit+0xda/0x330 net/netlink/genetlink.c:734
 genl_family_rcv_msg net/netlink/genetlink.c:833 [inline]
 genl_rcv_msg+0x441/0x780 net/netlink/genetlink.c:850
 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
 genl_rcv+0x24/0x40 net/netlink/genetlink.c:861
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0x154/0x190 net/socket.c:734
 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdd66a8f359
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
RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359
RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003
RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000
 &lt;/TASK&gt;
The buggy address belongs to the variable:
 ksmbd_nl_policy+0x100/0xa80
The buggy address belongs to the physical page:
page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4b
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
 ffffffff8f24b000: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 ffffffff8f24b080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
&gt;ffffffff8f24b100: f9 f9 f9 f9 00 00 f9 f9 f9 f9 f9 f9 00 00 07 f9
                   ^
 ffffffff8f24b180: f9 f9 f9 f9 00 05 f9 f9 f9 f9 f9 f9 00 00 00 05
 ffffffff8f24b200: f9 f9 f9 f9 00 00 03 f9 f9 f9 f9 f9 00 00 04 f9
==================================================================
To fix it, add a placeholder named __KSMBD_EVENT_MAX and let
KSMBD_EVENT_MAX to be its original value - 1 according to what other
netlink families do. Also change two sites that refer the
KSMBD_EVENT_MAX to correct value.
CVE-2024-26589:In the Linux kernel, the following vulnerability has been resolved:
bpf: Reject variable offset alu on PTR_TO_FLOW_KEYS
For PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed off
for validation. However, variable offset ptr alu is not prohibited
for this ptr kind. So the variable offset is not checked.
The following prog is accepted:
  func#0 @0
  0: R1=ctx() R10=fp0
  0: (bf) r6 = r1                       ; R1=ctx() R6_w=ctx()
  1: (79) r7 = *(u64 *)(r6 +144)        ; R6_w=ctx() R7_w=flow_keys()
  2: (b7) r8 = 1024                     ; R8_w=1024
  3: (37) r8 /= 1                       ; R8_w=scalar()
  4: (57) r8 &amp;= 1024                    ; R8_w=scalar(smin=smin32=0,
  smax=umax=smax32=umax32=1024,var_off=(0x0; 0x400))
  5: (0f) r7 += r8
  mark_precise: frame0: last_idx 5 first_idx 0 subseq_idx -1
  mark_precise: frame0: regs=r8 stack= before 4: (57) r8 &amp;= 1024
  mark_precise: frame0: regs=r8 stack= before 3: (37) r8 /= 1
  mark_precise: frame0: regs=r8 stack= before 2: (b7) r8 = 1024
  6: R7_w=flow_keys(smin=smin32=0,smax=umax=smax32=umax32=1024,var_off
  =(0x0; 0x400)) R8_w=scalar(smin=smin32=0,smax=umax=smax32=umax32=1024,
  var_off=(0x0; 0x400))
  6: (79) r0 = *(u64 *)(r7 +0)          ; R0_w=scalar()
  7: (95) exit
This prog loads flow_keys to r7, and adds the variable offset r8
to r7, and finally causes out-of-bounds access:
  BUG: unable to handle page fault for address: ffffc90014c80038
  [...]
  Call Trace:
   &lt;TASK&gt;
   bpf_dispatcher_nop_func include/linux/bpf.h:1231 [inline]
   __bpf_prog_run include/linux/filter.h:651 [inline]
   bpf_prog_run include/linux/filter.h:658 [inline]
   bpf_prog_run_pin_on_cpu include/linux/filter.h:675 [inline]
   bpf_flow_dissect+0x15f/0x350 net/core/flow_dissector.c:991
   bpf_prog_test_run_flow_dissector+0x39d/0x620 net/bpf/test_run.c:1359
   bpf_prog_test_run kernel/bpf/syscall.c:4107 [inline]
   __sys_bpf+0xf8f/0x4560 kernel/bpf/syscall.c:5475
   __do_sys_bpf kernel/bpf/syscall.c:5561 [inline]
   __se_sys_bpf kernel/bpf/syscall.c:5559 [inline]
   __x64_sys_bpf+0x73/0xb0 kernel/bpf/syscall.c:5559
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0x3f/0x110 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x63/0x6b
Fix this by rejecting ptr alu with variable offset on flow_keys.
Applying the patch rejects the program with &quot;R7 pointer arithmetic
on flow_keys prohibited&quot;.
CVE-2024-26597:In the Linux kernel, the following vulnerability has been resolved:
net: qualcomm: rmnet: fix global oob in rmnet_policy
The variable rmnet_link_ops assign a *bigger* maxtype which leads to a
global out-of-bounds read when parsing the netlink attributes. See bug
trace below:
==================================================================
BUG: KASAN: global-out-of-bounds in validate_nla lib/nlattr.c:386 [inline]
BUG: KASAN: global-out-of-bounds in __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207
CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G                 N 6.1.0 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0x8b/0xb3 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:284 [inline]
 print_report+0x172/0x475 mm/kasan/report.c:395
 kasan_report+0xbb/0x1c0 mm/kasan/report.c:495
 validate_nla lib/nlattr.c:386 [inline]
 __nla_validate_parse+0x24af/0x2750 lib/nlattr.c:600
 __nla_parse+0x3e/0x50 lib/nlattr.c:697
 nla_parse_nested_deprecated include/net/netlink.h:1248 [inline]
 __rtnl_newlink+0x50a/0x1880 net/core/rtnetlink.c:3485
 rtnl_newlink+0x64/0xa0 net/core/rtnetlink.c:3594
 rtnetlink_rcv_msg+0x43c/0xd70 net/core/rtnetlink.c:6091
 netlink_rcv_skb+0x14f/0x410 net/netlink/af_netlink.c:2540
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x54e/0x800 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x930/0xe50 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg+0x154/0x190 net/socket.c:734
 ____sys_sendmsg+0x6df/0x840 net/socket.c:2482
 ___sys_sendmsg+0x110/0x1b0 net/socket.c:2536
 __sys_sendmsg+0xf3/0x1c0 net/socket.c:2565
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
RIP: 0033:0x7fdcf2072359
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
RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359
RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003
RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000
 &lt;/TASK&gt;
The buggy address belongs to the variable:
 rmnet_policy+0x30/0xe0
The buggy address belongs to the physical page:
page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243
flags: 0x200000000001000(reserved|node=0|zone=2)
raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000
raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
 ffffffff92c43780: f9 f9 f9 f9 00 00 00 02 f9 f9 f9 f9 00 00 00 07
 ffffffff92c43800: f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9 06 f9 f9 f9
&gt;ffffffff92c43880: f9 f9 f9 f9 00 00 00 00 00 00 f9 f9 f9 f9 f9 f9
                                                 ^
 ffffffff92c43900: 00 00 00 00 00 00 00 00 07 f9 f9 f9 f9 f9 f9 f9
 ffffffff92c43980: 00 00 00 07 f9 f9 f9 f9 00 00 00 05 f9 f9 f9 f9
According to the comment of `nla_parse_nested_deprecated`, the maxtype
should be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.
CVE-2024-26606:In the Linux kernel, the following vulnerability has been resolved:
binder: signal epoll threads of self-work
In (e)poll mode, threads often depend on I/O events to determine when
data is ready for consumption. Within binder, a thread may initiate a
command via BINDER_WRITE_READ without a read buffer and then make use
of epoll_wait() or similar to consume any responses afterwards.
It is then crucial that epoll threads are signaled via wakeup when they
queue their own work. Otherwise, they risk waiting indefinitely for an
event leaving their work unhandled. What is worse, subsequent commands
won't trigger a wakeup either as the thread has pending work.
CVE-2023-52477:In the Linux kernel, the following vulnerability has been resolved:
usb: hub: Guard against accesses to uninitialized BOS descriptors
Many functions in drivers/usb/core/hub.c and drivers/usb/core/hub.h
access fields inside udev-&gt;bos without checking if it was allocated and
initialized. If usb_get_bos_descriptor() fails for whatever
reason, udev-&gt;bos will be NULL and those accesses will result in a
crash:
BUG: kernel NULL pointer dereference, address: 0000000000000018
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 5 PID: 17818 Comm: kworker/5:1 Tainted: G W 5.15.108-18910-gab0e1cb584e1 #1 &lt;HASH:1f9e 1&gt;
Hardware name: Google Kindred/Kindred, BIOS Google_Kindred.12672.413.0 02/03/2021
Workqueue: usb_hub_wq hub_event
RIP: 0010:hub_port_reset+0x193/0x788
Code: 89 f7 e8 20 f7 15 00 48 8b 43 08 80 b8 96 03 00 00 03 75 36 0f b7 88 92 03 00 00 81 f9 10 03 00 00 72 27 48 8b 80 a8 03 00 00 &lt;48&gt; 83 78 18 00 74 19 48 89 df 48 8b 75 b0 ba 02 00 00 00 4c 89 e9
RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310
RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840
RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060
R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000
R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0
Call Trace:
hub_event+0x73f/0x156e
? hub_activate+0x5b7/0x68f
process_one_work+0x1a2/0x487
worker_thread+0x11a/0x288
kthread+0x13a/0x152
? process_one_work+0x487/0x487
? kthread_associate_blkcg+0x70/0x70
ret_from_fork+0x1f/0x30
Fall back to a default behavior if the BOS descriptor isn't accessible
and skip all the functionalities that depend on it: LPM support checks,
Super Speed capabilitiy checks, U1/U2 states setup.
CVE-2023-52454:In the Linux kernel, the following vulnerability has been resolved:
nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU length
If the host sends an H2CData command with an invalid DATAL,
the kernel may crash in nvmet_tcp_build_pdu_iovec().
Unable to handle kernel NULL pointer dereference at
virtual address 0000000000000000
lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]
Call trace:
  process_one_work+0x174/0x3c8
  worker_thread+0x2d0/0x3e8
  kthread+0x104/0x110
Fix the bug by raising a fatal error if DATAL isn't coherent
with the packet size.
Also, the PDU length should never exceed the MAXH2CDATA parameter which
has been communicated to the host in nvmet_tcp_handle_icreq().
CVE-2023-52476:In the Linux kernel, the following vulnerability has been resolved:
perf/x86/lbr: Filter vsyscall addresses
We found that a panic can occur when a vsyscall is made while LBR sampling
is active. If the vsyscall is interrupted (NMI) for perf sampling, this
call sequence can occur (most recent at top):
    __insn_get_emulate_prefix()
    insn_get_emulate_prefix()
    insn_get_prefixes()
    insn_get_opcode()
    decode_branch_type()
    get_branch_type()
    intel_pmu_lbr_filter()
    intel_pmu_handle_irq()
    perf_event_nmi_handler()
Within __insn_get_emulate_prefix() at frame 0, a macro is called:
    peek_nbyte_next(insn_byte_t, insn, i)
Within this macro, this dereference occurs:
    (insn)-&gt;next_byte
Inspecting registers at this point, the value of the next_byte field is the
address of the vsyscall made, for example the location of the vsyscall
version of gettimeofday() at 0xffffffffff600000. The access to an address
in the vsyscall region will trigger an oops due to an unhandled page fault.
To fix the bug, filtering for vsyscalls can be done when
determining the branch type. This patch will return
a &quot;none&quot; branch if a kernel address if found to lie in the
vsyscall region.
CVE-2024-26654:In the Linux kernel, the following vulnerability has been resolved:
ALSA: sh: aica: reorder cleanup operations to avoid UAF bugs
The dreamcastcard-&gt;timer could schedule the spu_dma_work and the
spu_dma_work could also arm the dreamcastcard-&gt;timer.
When the snd_pcm_substream is closing, the aica_channel will be
deallocated. But it could still be dereferenced in the worker
thread. The reason is that del_timer() will return directly
regardless of whether the timer handler is running or not and
the worker could be rescheduled in the timer handler. As a result,
the UAF bug will happen. The racy situation is shown below:
      (Thread 1)                 |      (Thread 2)
snd_aicapcm_pcm_close()          |
 ...                             |  run_spu_dma() //worker
                                 |    mod_timer()
  flush_work()                   |
  del_timer()                    |  aica_period_elapsed() //timer
  kfree(dreamcastcard-&gt;channel)  |    schedule_work()
                                 |  run_spu_dma() //worker
  ...                            |    dreamcastcard-&gt;channel-&gt; //USE
In order to mitigate this bug and other possible corner cases,
call mod_timer() conditionally in run_spu_dma(), then implement
PCM sync_stop op to cancel both the timer and worker. The sync_stop
op will be called from PCM core appropriately when needed.
CVE-2024-26603:In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Stop relying on userspace for info to fault in xsave buffer
Before this change, the expected size of the user space buffer was
taken from fx_sw-&gt;xstate_size. fx_sw-&gt;xstate_size can be changed
from user-space, so it is possible construct a sigreturn frame where:
 * fx_sw-&gt;xstate_size is smaller than the size required by valid bits in
   fx_sw-&gt;xfeatures.
 * user-space unmaps parts of the sigrame fpu buffer so that not all of
   the buffer required by xrstor is accessible.
In this case, xrstor tries to restore and accesses the unmapped area
which results in a fault. But fault_in_readable succeeds because buf +
fx_sw-&gt;xstate_size is within the still mapped area, so it goes back and
tries xrstor again. It will spin in this loop forever.
Instead, fault in the maximum size which can be touched by XRSTOR (taken
from fpstate-&gt;user_size).
[ dhansen: tweak subject / changelog ]
CVE-2024-26644:In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't abort filesystem when attempting to snapshot deleted subvolume
If the source file descriptor to the snapshot ioctl refers to a deleted
subvolume, we get the following abort:
  BTRFS: Transaction aborted (error -2)
  WARNING: CPU: 0 PID: 833 at fs/btrfs/transaction.c:1875 create_pending_snapshot+0x1040/0x1190 [btrfs]
  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
  CPU: 0 PID: 833 Comm: t_snapshot_dele Not tainted 6.7.0-rc6 #2
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
  RIP: 0010:create_pending_snapshot+0x1040/0x1190 [btrfs]
  RSP: 0018:ffffa09c01337af8 EFLAGS: 00010282
  RAX: 0000000000000000 RBX: ffff9982053e7c78 RCX: 0000000000000027
  RDX: ffff99827dc20848 RSI: 0000000000000001 RDI: ffff99827dc20840
  RBP: ffffa09c01337c00 R08: 0000000000000000 R09: ffffa09c01337998
  R10: 0000000000000003 R11: ffffffffb96da248 R12: fffffffffffffffe
  R13: ffff99820535bb28 R14: ffff99820b7bd000 R15: ffff99820381ea80
  FS:  00007fe20aadabc0(0000) GS:ffff99827dc00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000559a120b502f CR3: 00000000055b6000 CR4: 00000000000006f0
  Call Trace:
   &lt;TASK&gt;
   ? create_pending_snapshot+0x1040/0x1190 [btrfs]
   ? __warn+0x81/0x130
   ? create_pending_snapshot+0x1040/0x1190 [btrfs]
   ? report_bug+0x171/0x1a0
   ? handle_bug+0x3a/0x70
   ? exc_invalid_op+0x17/0x70
   ? asm_exc_invalid_op+0x1a/0x20
   ? create_pending_snapshot+0x1040/0x1190 [btrfs]
   ? create_pending_snapshot+0x1040/0x1190 [btrfs]
   create_pending_snapshots+0x92/0xc0 [btrfs]
   btrfs_commit_transaction+0x66b/0xf40 [btrfs]
   btrfs_mksubvol+0x301/0x4d0 [btrfs]
   btrfs_mksnapshot+0x80/0xb0 [btrfs]
   __btrfs_ioctl_snap_create+0x1c2/0x1d0 [btrfs]
   btrfs_ioctl_snap_create_v2+0xc4/0x150 [btrfs]
   btrfs_ioctl+0x8a6/0x2650 [btrfs]
   ? kmem_cache_free+0x22/0x340
   ? do_sys_openat2+0x97/0xe0
   __x64_sys_ioctl+0x97/0xd0
   do_syscall_64+0x46/0xf0
   entry_SYSCALL_64_after_hwframe+0x6e/0x76
  RIP: 0033:0x7fe20abe83af
  RSP: 002b:00007ffe6eff1360 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
  RAX: ffffffffffffffda RBX: 0000000000000004 RCX: 00007fe20abe83af
  RDX: 00007ffe6eff23c0 RSI: 0000000050009417 RDI: 0000000000000003
  RBP: 0000000000000003 R08: 0000000000000000 R09: 00007fe20ad16cd0
  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
  R13: 00007ffe6eff13c0 R14: 00007fe20ad45000 R15: 0000559a120b6d58
   &lt;/TASK&gt;
  ---[ end trace 0000000000000000 ]---
  BTRFS: error (device vdc: state A) in create_pending_snapshot:1875: errno=-2 No such entry
  BTRFS info (device vdc: state EA): forced readonly
  BTRFS warning (device vdc: state EA): Skipping commit of aborted transaction.
  BTRFS: error (device vdc: state EA) in cleanup_transaction:2055: errno=-2 No such entry
This happens because create_pending_snapshot() initializes the new root
item as a copy of the source root item. This includes the refs field,
which is 0 for a deleted subvolume. The call to btrfs_insert_root()
therefore inserts a root with refs == 0. btrfs_get_new_fs_root() then
finds the root and returns -ENOENT if refs == 0, which causes
create_pending_snapshot() to abort.
Fix it by checking the source root's refs before attempting the
snapshot, but after locking subvol_sem to avoid racing with deletion.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2129</id>
		<title>An update for less is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32487" id="CVE-2024-32487" title="CVE-2024-32487" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="less" release="6.u3.fos23" version="590">
					<filename>less-590-6.u3.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2130</id>
		<title>An update for libdwarf is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2002" id="CVE-2024-2002" title="CVE-2024-2002" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2131</id>
		<title>An update for libreswan is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2357" id="CVE-2024-2357" title="CVE-2024-2357" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2132</id>
		<title>An update for libvirt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1441" id="CVE-2024-1441" title="CVE-2024-1441" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2494" id="CVE-2024-2494" title="CVE-2024-2494" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2496" id="CVE-2024-2496" title="CVE-2024-2496" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2133</id>
		<title>An update for llvm is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46049" id="CVE-2023-46049" title="CVE-2023-46049" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2134</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38575" id="CVE-2023-38575" title="CVE-2023-38575" type="cve"/>
		</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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2135</id>
		<title>An update for mod_http2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27316" id="CVE-2024-27316" title="CVE-2024-27316" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2136</id>
		<title>An update for mod_security is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48279" id="CVE-2022-48279" title="CVE-2022-48279" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2137</id>
		<title>An update for mozjs91 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23599" id="CVE-2023-23599" title="CVE-2023-23599" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23601" id="CVE-2023-23601" title="CVE-2023-23601" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23602" id="CVE-2023-23602" title="CVE-2023-23602" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2138</id>
		<title>An update for nghttp2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28182" id="CVE-2024-28182" title="CVE-2024-28182" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2139</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"/>
		</references>
		<description>CVE-2024-2511:Issue summary: Some non-default TLS server configurations can cause unbounded
memory growth when processing TLSv1.3 sessions
Impact summary: An attacker may exploit certain server configurations to trigger
unbounded memory growth that would lead to a Denial of Service
This problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option is
being used (but not if early_data support is also configured and the default
anti-replay protection is in use). In this case, under certain conditions, the
session cache can get into an incorrect state and it will fail to flush properly
as it fills. The session cache will continue to grow in an unbounded manner. A
malicious client could deliberately create the scenario for this failure to
force a Denial of Service. It may also happen by accident in normal operation.
This issue only affects TLS servers supporting TLSv1.3. It does not affect TLS
clients.
The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL
1.0.2 is also not affected by this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2140</id>
		<title>An update for openvswitch is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2639" id="CVE-2022-2639" title="CVE-2022-2639" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2141</id>
		<title>An update for pcp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3019" id="CVE-2024-3019" title="CVE-2024-3019" type="cve"/>
		</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 'Metrics settings' page of the Cockpit web interface. This flaw affects PCP versions 4.3.4 and newer.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2142</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2756" id="CVE-2024-2756" title="CVE-2024-2756" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3096" id="CVE-2024-3096" title="CVE-2024-3096" type="cve"/>
		</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's browser.
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's account by attempting to sign in with a blank string.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2143</id>
		<title>An update for python-aiosmtpd is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27305" id="CVE-2024-27305" title="CVE-2024-27305" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2144</id>
		<title>An update for python-pillow is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28219" id="CVE-2024-28219" title="CVE-2024-28219" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2145</id>
		<title>An update for python-pymongo is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21506" id="CVE-2024-21506" title="CVE-2024-21506" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2146</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27043" id="CVE-2023-27043" title="CVE-2023-27043" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2147</id>
		<title>An update for tcpdump is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2397" id="CVE-2024-2397" title="CVE-2024-2397" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2148</id>
		<title>An update for telnet is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39028" id="CVE-2022-39028" title="CVE-2022-39028" type="cve"/>
		</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 &quot;telnet/tcp server failing (looping), service terminated&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2149</id>
		<title>An update for unixODBC is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1013" id="CVE-2024-1013" title="CVE-2024-1013" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2150</id>
		<title>An update for util-linux is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28085" id="CVE-2024-28085" title="CVE-2024-28085" type="cve"/>
		</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' 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2151</id>
		<title>An update for varnish is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30156" id="CVE-2024-30156" title="CVE-2024-30156" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2152</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0666" id="CVE-2023-0666" title="CVE-2023-0666" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31083" id="CVE-2024-31083" title="CVE-2024-31083" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31080" id="CVE-2024-31080" title="CVE-2024-31080" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31081" id="CVE-2024-31081" title="CVE-2024-31081" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31082" id="CVE-2024-31082" title="CVE-2024-31082" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31083" id="CVE-2024-31083" title="CVE-2024-31083" type="cve"/>
		</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.
CVE-2024-31080:A heap-based buffer over-read vulnerability was found in the X.org server'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'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.
CVE-2024-31081:A heap-based buffer over-read vulnerability was found in the X.org server'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'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.
CVE-2024-31082:A heap-based buffer over-read vulnerability was found in the X.org server'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'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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-04-29"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31080" id="CVE-2024-31080" title="CVE-2024-31080" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31081" id="CVE-2024-31081" title="CVE-2024-31081" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31083" id="CVE-2024-31083" title="CVE-2024-31083" type="cve"/>
		</references>
		<description>CVE-2024-31080:A heap-based buffer over-read vulnerability was found in the X.org server'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'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.
CVE-2024-31081:A heap-based buffer over-read vulnerability was found in the X.org server'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'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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2155</id>
		<title>An update for ceph is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46159" id="CVE-2023-46159" title="CVE-2023-46159" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2156</id>
		<title>An update for cjson is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31755" id="CVE-2024-31755" title="CVE-2024-31755" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2157</id>
		<title>An update for cockpit is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35850" id="CVE-2020-35850" title="CVE-2020-35850" type="cve"/>
		</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 &quot;I don't think [it] is a big real-life issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="cockpit" release="14.u2.fos23" version="178">
					<filename>cockpit-178-14.u2.fos23.aarch64.rpm</filename>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2158</id>
		<title>An update for fdupes is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48682" id="CVE-2022-48682" title="CVE-2022-48682" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2159</id>
		<title>An update for firefox is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44488" id="CVE-2023-44488" title="CVE-2023-44488" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2160</id>
		<title>An update for freerdp is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32039" id="CVE-2024-32039" title="CVE-2024-32039" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32040" id="CVE-2024-32040" title="CVE-2024-32040" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32041" id="CVE-2024-32041" title="CVE-2024-32041" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32458" id="CVE-2024-32458" title="CVE-2024-32458" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32459" id="CVE-2024-32459" title="CVE-2024-32459" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32460" id="CVE-2024-32460" title="CVE-2024-32460" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32658" id="CVE-2024-32658" title="CVE-2024-32658" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32659" id="CVE-2024-32659" title="CVE-2024-32659" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32660" id="CVE-2024-32660" title="CVE-2024-32660" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32661" id="CVE-2024-32661" title="CVE-2024-32661" type="cve"/>
		</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).
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`).
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.
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).
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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2161</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52722" id="CVE-2023-52722" title="CVE-2023-52722" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2162</id>
		<title>An update for glibc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33599" id="CVE-2024-33599" title="CVE-2024-33599" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33601" id="CVE-2024-33601" title="CVE-2024-33601" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33600" id="CVE-2024-33600" title="CVE-2024-33600" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33602" id="CVE-2024-33602" title="CVE-2024-33602" type="cve"/>
		</references>
		<description>CVE-2024-33599:nscd: Stack-based buffer overflow in netgroup cache
If the Name Service Cache Daemon's (nscd) fixed size cache is exhausted
by client requests then a subsequent client request for netgroup data
may result in a stack-based buffer overflow.  This flaw was introduced
in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.
CVE-2024-33601:nscd: netgroup cache may terminate daemon on memory allocation failure
The Name Service Cache Daemon's (nscd) netgroup cache uses xmalloc or
xrealloc and these functions may terminate the process due to a memory
allocation failure resulting in a denial of service to the clients.  The
flaw was introduced in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.
CVE-2024-33600:nscd: Null pointer crashes after notfound response
If the Name Service Cache Daemon's (nscd) cache fails to add a not-found
netgroup response to the cache, the client request can result in a null
pointer dereference.  This flaw was introduced in glibc 2.15 when the
cache was added to nscd.
This vulnerability is only present in the nscd binary.
CVE-2024-33602:nscd: netgroup cache assumes NSS callback uses in-buffer strings
The Name Service Cache Daemon's (nscd) netgroup cache can corrupt memory
when the NSS callback does not store all strings in the provided buffer.
The flaw was introduced in glibc 2.15 when the cache was added to nscd.
This vulnerability is only present in the nscd binary.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2163</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45289" id="CVE-2023-45289" title="CVE-2023-45289" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45290" id="CVE-2023-45290" title="CVE-2023-45290" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24783" id="CVE-2024-24783" title="CVE-2024-24783" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24785" id="CVE-2024-24785" title="CVE-2024-24785" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24784" id="CVE-2024-24784" title="CVE-2024-24784" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45288" id="CVE-2023-45288" title="CVE-2023-45288" type="cve"/>
		</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 &quot;Authorization&quot; or &quot;Cookie&quot;. 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.
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.
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.
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.
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.
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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2164</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38709" id="CVE-2023-38709" title="CVE-2023-38709" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24795" id="CVE-2024-24795" title="CVE-2024-24795" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27316" id="CVE-2024-27316" title="CVE-2024-27316" type="cve"/>
		</references>
		<description>CVE-2023-38709:Faulty input validation in the core of Apache allows malicious or exploitable backend/content generators to split HTTP responses.
This issue affects Apache HTTP Server: through 2.4.58.
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.
Users are recommended to upgrade to version 2.4.59, which fixes this issue.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2165</id>
		<title>An update for iSulad is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33632" id="CVE-2021-33632" title="CVE-2021-33632" type="cve"/>
		</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.
This issue affects iSulad: 2.0.18-13, from 2.1.4-1 through 2.1.4-2.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2166</id>
		<title>An update for iperf3 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26306" id="CVE-2024-26306" title="CVE-2024-26306" type="cve"/>
		</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 &quot;Everlasting ROBOT: the Marvin Attack&quot; by Hubert Kario.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2167</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52530" id="CVE-2023-52530" title="CVE-2023-52530" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52504" id="CVE-2023-52504" title="CVE-2023-52504" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47070" id="CVE-2021-47070" title="CVE-2021-47070" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52561" id="CVE-2023-52561" title="CVE-2023-52561" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52594" id="CVE-2023-52594" title="CVE-2023-52594" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52572" id="CVE-2023-52572" title="CVE-2023-52572" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26810" id="CVE-2024-26810" title="CVE-2024-26810" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47101" id="CVE-2021-47101" title="CVE-2021-47101" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52587" id="CVE-2023-52587" title="CVE-2023-52587" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27437" id="CVE-2024-27437" title="CVE-2024-27437" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26698" id="CVE-2024-26698" title="CVE-2024-26698" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52560" id="CVE-2023-52560" title="CVE-2023-52560" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52597" id="CVE-2023-52597" title="CVE-2023-52597" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52578" id="CVE-2023-52578" title="CVE-2023-52578" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52574" id="CVE-2023-52574" title="CVE-2023-52574" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52595" id="CVE-2023-52595" title="CVE-2023-52595" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26656" id="CVE-2024-26656" title="CVE-2024-26656" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52516" id="CVE-2023-52516" title="CVE-2023-52516" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52464" id="CVE-2023-52464" title="CVE-2023-52464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26759" id="CVE-2024-26759" title="CVE-2024-26759" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26751" id="CVE-2024-26751" title="CVE-2024-26751" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26778" id="CVE-2024-26778" title="CVE-2024-26778" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26772" id="CVE-2024-26772" title="CVE-2024-26772" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52640" id="CVE-2023-52640" title="CVE-2023-52640" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26695" id="CVE-2024-26695" title="CVE-2024-26695" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26736" id="CVE-2024-26736" title="CVE-2024-26736" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26777" id="CVE-2024-26777" title="CVE-2024-26777" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52598" id="CVE-2023-52598" title="CVE-2023-52598" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26771" id="CVE-2024-26771" title="CVE-2024-26771" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52503" id="CVE-2023-52503" title="CVE-2023-52503" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52493" id="CVE-2023-52493" title="CVE-2023-52493" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26795" id="CVE-2024-26795" title="CVE-2024-26795" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52607" id="CVE-2023-52607" title="CVE-2023-52607" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26615" id="CVE-2024-26615" title="CVE-2024-26615" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52491" id="CVE-2023-52491" title="CVE-2023-52491" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7042" id="CVE-2023-7042" title="CVE-2023-7042" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52617" id="CVE-2023-52617" title="CVE-2023-52617" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52608" id="CVE-2023-52608" title="CVE-2023-52608" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52498" id="CVE-2023-52498" title="CVE-2023-52498" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47182" id="CVE-2021-47182" title="CVE-2021-47182" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24861" id="CVE-2024-24861" title="CVE-2024-24861" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52492" id="CVE-2023-52492" title="CVE-2023-52492" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26764" id="CVE-2024-26764" title="CVE-2024-26764" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52441" id="CVE-2023-52441" title="CVE-2023-52441" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6270" id="CVE-2023-6270" title="CVE-2023-6270" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26885" id="CVE-2024-26885" title="CVE-2024-26885" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26884" id="CVE-2024-26884" title="CVE-2024-26884" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26883" id="CVE-2024-26883" title="CVE-2024-26883" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26882" id="CVE-2024-26882" title="CVE-2024-26882" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26817" id="CVE-2024-26817" title="CVE-2024-26817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47211" id="CVE-2021-47211" title="CVE-2021-47211" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26843" id="CVE-2024-26843" title="CVE-2024-26843" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26840" id="CVE-2024-26840" title="CVE-2024-26840" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26874" id="CVE-2024-26874" title="CVE-2024-26874" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26900" id="CVE-2024-26900" title="CVE-2024-26900" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26894" id="CVE-2024-26894" title="CVE-2024-26894" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52642" id="CVE-2023-52642" title="CVE-2023-52642" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26839" id="CVE-2024-26839" title="CVE-2024-26839" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26855" id="CVE-2024-26855" title="CVE-2024-26855" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26893" id="CVE-2024-26893" title="CVE-2024-26893" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25739" id="CVE-2024-25739" title="CVE-2024-25739" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47212" id="CVE-2021-47212" title="CVE-2021-47212" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26901" id="CVE-2024-26901" title="CVE-2024-26901" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26875" id="CVE-2024-26875" title="CVE-2024-26875" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48655" id="CVE-2022-48655" title="CVE-2022-48655" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26898" id="CVE-2024-26898" title="CVE-2024-26898" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26669" id="CVE-2024-26669" title="CVE-2024-26669" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26680" id="CVE-2024-26680" title="CVE-2024-26680" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26668" id="CVE-2024-26668" title="CVE-2024-26668" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52620" id="CVE-2023-52620" title="CVE-2023-52620" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27073" id="CVE-2024-27073" title="CVE-2024-27073" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27008" id="CVE-2024-27008" title="CVE-2024-27008" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26958" id="CVE-2024-26958" title="CVE-2024-26958" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26972" id="CVE-2024-26972" title="CVE-2024-26972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26811" id="CVE-2024-26811" title="CVE-2024-26811" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26828" id="CVE-2024-26828" title="CVE-2024-26828" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26870" id="CVE-2024-26870" title="CVE-2024-26870" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27059" id="CVE-2024-27059" title="CVE-2024-27059" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27043" id="CVE-2024-27043" title="CVE-2024-27043" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26965" id="CVE-2024-26965" title="CVE-2024-26965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26812" id="CVE-2024-26812" title="CVE-2024-26812" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26961" id="CVE-2024-26961" title="CVE-2024-26961" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26931" id="CVE-2024-26931" title="CVE-2024-26931" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52650" id="CVE-2023-52650" title="CVE-2023-52650" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26704" id="CVE-2024-26704" title="CVE-2024-26704" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26791" id="CVE-2024-26791" title="CVE-2024-26791" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26689" id="CVE-2024-26689" title="CVE-2024-26689" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26950" id="CVE-2024-26950" title="CVE-2024-26950" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27000" id="CVE-2024-27000" title="CVE-2024-27000" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26878" id="CVE-2024-26878" title="CVE-2024-26878" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27075" id="CVE-2024-27075" title="CVE-2024-27075" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27389" id="CVE-2024-27389" title="CVE-2024-27389" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26973" id="CVE-2024-26973" title="CVE-2024-26973" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26993" id="CVE-2024-26993" title="CVE-2024-26993" type="cve"/>
		</references>
		<description>CVE-2023-52530:In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: fix potential key use-after-free
When ieee80211_key_link() is called by ieee80211_gtk_rekey_add()
but returns 0 due to KRACK protection (identical key reinstall),
ieee80211_gtk_rekey_add() will still return a pointer into the
key, in a potential use-after-free. This normally doesn't happen
since it's only called by iwlwifi in case of WoWLAN rekey offload
which has its own KRACK protection, but still better to fix, do
that by returning an error code and converting that to success on
the cfg80211 boundary only, leaving the error for bad callers of
ieee80211_gtk_rekey_add().
CVE-2023-52504:In the Linux kernel, the following vulnerability has been resolved:
x86/alternatives: Disable KASAN in apply_alternatives()
Fei has reported that KASAN triggers during apply_alternatives() on
a 5-level paging machine:
	BUG: KASAN: out-of-bounds in rcu_is_watching()
	Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0
	...
	__asan_load4()
	rcu_is_watching()
	trace_hardirqs_on()
	text_poke_early()
	apply_alternatives()
	...
On machines with 5-level paging, cpu_feature_enabled(X86_FEATURE_LA57)
gets patched. It includes KASAN code, where KASAN_SHADOW_START depends on
__VIRTUAL_MASK_SHIFT, which is defined with cpu_feature_enabled().
KASAN gets confused when apply_alternatives() patches the
KASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_START
static, by replacing __VIRTUAL_MASK_SHIFT with 56, works around the issue.
Fix it for real by disabling KASAN while the kernel is patching alternatives.
[ mingo: updated the changelog ]
CVE-2021-47070:In the Linux kernel, the following vulnerability has been resolved:
uio_hv_generic: Fix another memory leak in error handling paths
Memory allocated by 'vmbus_alloc_ring()' at the beginning of the probe
function is never freed in the error handling path.
Add the missing 'vmbus_free_ring()' call.
Note that it is already freed in the .remove function.
CVE-2023-52561:In the Linux kernel, the following vulnerability has been resolved:
arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reserved
Adding a reserved memory region for the framebuffer memory
(the splash memory region set up by the bootloader).
It fixes a kernel panic (arm-smmu: Unhandled context fault
at this particular memory region) reported on DB845c running
v5.10.y.
CVE-2023-52594:In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: Fix potential array-index-out-of-bounds read in ath9k_htc_txstatus()
Fix an array-index-out-of-bounds read in ath9k_htc_txstatus(). The bug
occurs when txs-&gt;cnt, data from a URB provided by a USB device, is
bigger than the size of the array txs-&gt;txstatus, which is
HTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bug
handling code after the check. Make the function return if that is the
case.
Found by a modified version of syzkaller.
UBSAN: array-index-out-of-bounds in htc_drv_txrx.c
index 13 is out of range for type '__wmi_event_txstatus [12]'
Call Trace:
 ath9k_htc_txstatus
 ath9k_wmi_event_tasklet
 tasklet_action_common
 __do_softirq
 irq_exit_rxu
 sysvec_apic_timer_interrupt
CVE-2023-52572:In the Linux kernel, the following vulnerability has been resolved:
cifs: Fix UAF in cifs_demultiplex_thread()
There is a UAF when xfstests on cifs:
  BUG: KASAN: use-after-free in smb2_is_network_name_deleted+0x27/0x160
  Read of size 4 at addr ffff88810103fc08 by task cifsd/923
  CPU: 1 PID: 923 Comm: cifsd Not tainted 6.1.0-rc4+ #45
  ...
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x34/0x44
   print_report+0x171/0x472
   kasan_report+0xad/0x130
   kasan_check_range+0x145/0x1a0
   smb2_is_network_name_deleted+0x27/0x160
   cifs_demultiplex_thread.cold+0x172/0x5a4
   kthread+0x165/0x1a0
   ret_from_fork+0x1f/0x30
   &lt;/TASK&gt;
  Allocated by task 923:
   kasan_save_stack+0x1e/0x40
   kasan_set_track+0x21/0x30
   __kasan_slab_alloc+0x54/0x60
   kmem_cache_alloc+0x147/0x320
   mempool_alloc+0xe1/0x260
   cifs_small_buf_get+0x24/0x60
   allocate_buffers+0xa1/0x1c0
   cifs_demultiplex_thread+0x199/0x10d0
   kthread+0x165/0x1a0
   ret_from_fork+0x1f/0x30
  Freed by task 921:
   kasan_save_stack+0x1e/0x40
   kasan_set_track+0x21/0x30
   kasan_save_free_info+0x2a/0x40
   ____kasan_slab_free+0x143/0x1b0
   kmem_cache_free+0xe3/0x4d0
   cifs_small_buf_release+0x29/0x90
   SMB2_negotiate+0x8b7/0x1c60
   smb2_negotiate+0x51/0x70
   cifs_negotiate_protocol+0xf0/0x160
   cifs_get_smb_ses+0x5fa/0x13c0
   mount_get_conns+0x7a/0x750
   cifs_mount+0x103/0xd00
   cifs_smb3_do_mount+0x1dd/0xcb0
   smb3_get_tree+0x1d5/0x300
   vfs_get_tree+0x41/0xf0
   path_mount+0x9b3/0xdd0
   __x64_sys_mount+0x190/0x1d0
   do_syscall_64+0x35/0x80
   entry_SYSCALL_64_after_hwframe+0x46/0xb0
The UAF is because:
 mount(pid: 921)               | cifsd(pid: 923)
-------------------------------|-------------------------------
                               | cifs_demultiplex_thread
SMB2_negotiate                 |
 cifs_send_recv                |
  compound_send_recv           |
   smb_send_rqst               |
    wait_for_response          |
     wait_event_state      [1] |
                               |  standard_receive3
                               |   cifs_handle_standard
                               |    handle_mid
                               |     mid-&gt;resp_buf = buf;  [2]
                               |     dequeue_mid           [3]
     KILL the process      [4] |
    resp_iov[i].iov_base = buf |
 free_rsp_buf              [5] |
                               |   is_network_name_deleted [6]
                               |   callback
1. After send request to server, wait the response until
    mid-&gt;mid_state != SUBMITTED;
2. Receive response from server, and set it to mid;
3. Set the mid state to RECEIVED;
4. Kill the process, the mid state already RECEIVED, get 0;
5. Handle and release the negotiate response;
6. UAF.
It can be easily reproduce with add some delay in [3] - [6].
Only sync call has the problem since async call's callback is
executed in cifsd process.
Add an extra state to mark the mid state to READY before wakeup the
waitter, then it can get the resp safely.
CVE-2024-26810:In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Lock external INTx masking ops
Mask operations through config space changes to DisINTx may race INTx
configuration changes via ioctl.  Create wrappers that add locking for
paths outside of the core interrupt code.
In particular, irq_type is updated holding igate, therefore testing
is_intx() requires holding igate.  For example clearing DisINTx from
config space can otherwise race changes of the interrupt configuration.
This aligns interfaces which may trigger the INTx eventfd into two
camps, one side serialized by igate and the other only enabled while
INTx is configured.  A subsequent patch introduces synchronization for
the latter flows.
CVE-2021-47101:In the Linux kernel, the following vulnerability has been resolved:
asix: fix uninit-value in asix_mdio_read()
asix_read_cmd() may read less than sizeof(smsr) bytes and in this case
smsr will be uninitialized.
Fail log:
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
BUG: KMSAN: uninit-value in asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
BUG: KMSAN: uninit-value in asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline]
 asix_check_host_enable drivers/net/usb/asix_common.c:82 [inline] drivers/net/usb/asix_common.c:497
 asix_mdio_read+0x3c1/0xb00 drivers/net/usb/asix_common.c:497 drivers/net/usb/asix_common.c:497
CVE-2023-52587:In the Linux kernel, the following vulnerability has been resolved:
IB/ipoib: Fix mcast list locking
Releasing the `priv-&gt;lock` while iterating the `priv-&gt;multicast_list` in
`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` to
remove the items while in the middle of iteration. If the mcast is removed
while the lock was dropped, the for loop spins forever resulting in a hard
lockup (as was reported on RHEL 4.18.0-372.75.1.el8_6 kernel):
    Task A (kworker/u72:2 below)       | Task B (kworker/u72:0 below)
    -----------------------------------+-----------------------------------
    ipoib_mcast_join_task(work)        | ipoib_ib_dev_flush_light(work)
      spin_lock_irq(&amp;priv-&gt;lock)       | __ipoib_ib_dev_flush(priv, ...)
      list_for_each_entry(mcast,       | ipoib_mcast_dev_flush(dev = priv-&gt;dev)
          &amp;priv-&gt;multicast_list, list) |
        ipoib_mcast_join(dev, mcast)   |
          spin_unlock_irq(&amp;priv-&gt;lock) |
                                       |   spin_lock_irqsave(&amp;priv-&gt;lock, flags)
                                       |   list_for_each_entry_safe(mcast, tmcast,
                                       |                  &amp;priv-&gt;multicast_list, list)
                                       |     list_del(&amp;mcast-&gt;list);
                                       |     list_add_tail(&amp;mcast-&gt;list, &amp;remove_list)
                                       |   spin_unlock_irqrestore(&amp;priv-&gt;lock, flags)
          spin_lock_irq(&amp;priv-&gt;lock)   |
                                       |   ipoib_mcast_remove_list(&amp;remove_list)
   (Here, `mcast` is no longer on the  |     list_for_each_entry_safe(mcast, tmcast,
    `priv-&gt;multicast_list` and we keep |                            remove_list, list)
    spinning on the `remove_list` of   |  &gt;&gt;&gt;  wait_for_completion(&amp;mcast-&gt;done)
    the other thread which is blocked  |
    and the list is still valid on     |
    it's stack.)
Fix this by keeping the lock held and changing to GFP_ATOMIC to prevent
eventual sleeps.
Unfortunately we could not reproduce the lockup and confirm this fix but
based on the code review I think this fix should address such lockups.
crash&gt; bc 31
PID: 747      TASK: ff1c6a1a007e8000  CPU: 31   COMMAND: &quot;kworker/u72:2&quot;
--
    [exception RIP: ipoib_mcast_join_task+0x1b1]
    RIP: ffffffffc0944ac1  RSP: ff646f199a8c7e00  RFLAGS: 00000002
    RAX: 0000000000000000  RBX: ff1c6a1a04dc82f8  RCX: 0000000000000000
                                  work (&amp;priv-&gt;mcast_task{,.work})
    RDX: ff1c6a192d60ac68  RSI: 0000000000000286  RDI: ff1c6a1a04dc8000
           &amp;mcast-&gt;list
    RBP: ff646f199a8c7e90   R8: ff1c699980019420   R9: ff1c6a1920c9a000
    R10: ff646f199a8c7e00  R11: ff1c6a191a7d9800  R12: ff1c6a192d60ac00
                                                         mcast
    R13: ff1c6a1d82200000  R14: ff1c6a1a04dc8000  R15: ff1c6a1a04dc82d8
           dev                    priv (&amp;priv-&gt;lock)     &amp;priv-&gt;multicast_list (aka head)
    ORIG_RAX: ffffffffffffffff  CS: 0010  SS: 0018
--- &lt;NMI exception stack&gt; ---
 #5 [ff646f199a8c7e00] ipoib_mcast_join_task+0x1b1 at ffffffffc0944ac1 [ib_ipoib]
 #6 [ff646f199a8c7e98] process_one_work+0x1a7 at ffffffff9bf10967
crash&gt; rx ff646f199a8c7e68
ff646f199a8c7e68:  ff1c6a1a04dc82f8 &lt;&lt;&lt; work = &amp;priv-&gt;mcast_task.work
crash&gt; list -hO ipoib_dev_priv.multicast_list ff1c6a1a04dc8000
(empty)
crash&gt; ipoib_dev_priv.mcast_task.work.func,mcast_mutex.owner.counter ff1c6a1a04dc8000
  mcast_task.work.func = 0xffffffffc0944910 &lt;ipoib_mcast_join_task&gt;,
  mcast_mutex.owner.counter = 0xff1c69998efec000
crash&gt; b 8
PID: 8        TASK: ff1c69998efec000  CPU: 33   COMMAND: &quot;kworker/u72:0&quot;
--
 #3 [ff646f1980153d50] wait_for_completion+0x96 at ffffffff9c7d7646
 #4 [ff646f1980153d90] ipoib_mcast_remove_list+0x56 at ffffffffc0944dc6 [ib_ipoib]
 #5 [ff646f1980153de8] ipoib_mcast_dev_flush+0x1a7 at ffffffffc09455a7 [ib_ipoib]
 #6 [ff646f1980153e58] __ipoib_ib_dev_flush+0x1a4 at ffffffffc09431a4 [ib_ipoib]
 #7 [ff
---truncated---
CVE-2024-27437:In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Disable auto-enable of exclusive INTx IRQ
Currently for devices requiring masking at the irqchip for INTx, ie.
devices without DisINTx support, the IRQ is enabled in request_irq()
and subsequently disabled as necessary to align with the masked status
flag.  This presents a window where the interrupt could fire between
these events, resulting in the IRQ incrementing the disable depth twice.
This would be unrecoverable for a user since the masked flag prevents
nested enables through vfio.
Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTx
is never auto-enabled, then unmask as required.
CVE-2024-26698:In the Linux kernel, the following vulnerability has been resolved:
hv_netvsc: Fix race condition between netvsc_probe and netvsc_remove
In commit ac5047671758 (&quot;hv_netvsc: Disable NAPI before closing the
VMBus channel&quot;), napi_disable was getting called for all channels,
including all subchannels without confirming if they are enabled or not.
This caused hv_netvsc getting hung at napi_disable, when netvsc_probe()
has finished running but nvdev-&gt;subchan_work has not started yet.
netvsc_subchan_work() -&gt; rndis_set_subchannel() has not created the
sub-channels and because of that netvsc_sc_open() is not running.
netvsc_remove() calls cancel_work_sync(&amp;nvdev-&gt;subchan_work), for which
netvsc_subchan_work did not run.
netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPI
cannot be scheduled. Then netvsc_sc_open() -&gt; napi_enable will clear the
NAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does the
opposite.
Now during netvsc_device_remove(), when napi_disable is called for those
subchannels, napi_disable gets stuck on infinite msleep.
This fix addresses this problem by ensuring that napi_disable() is not
getting called for non-enabled NAPI struct.
But netif_napi_del() is still necessary for these non-enabled NAPI struct
for cleanup purpose.
Call trace:
[  654.559417] task:modprobe        state:D stack:    0 pid: 2321 ppid:  1091 flags:0x00004002
[  654.568030] Call Trace:
[  654.571221]  &lt;TASK&gt;
[  654.573790]  __schedule+0x2d6/0x960
[  654.577733]  schedule+0x69/0xf0
[  654.581214]  schedule_timeout+0x87/0x140
[  654.585463]  ? __bpf_trace_tick_stop+0x20/0x20
[  654.590291]  msleep+0x2d/0x40
[  654.593625]  napi_disable+0x2b/0x80
[  654.597437]  netvsc_device_remove+0x8a/0x1f0 [hv_netvsc]
[  654.603935]  rndis_filter_device_remove+0x194/0x1c0 [hv_netvsc]
[  654.611101]  ? do_wait_intr+0xb0/0xb0
[  654.615753]  netvsc_remove+0x7c/0x120 [hv_netvsc]
[  654.621675]  vmbus_remove+0x27/0x40 [hv_vmbus]
CVE-2023-52560:In the Linux kernel, the following vulnerability has been resolved:
mm/damon/vaddr-test: fix memory leak in damon_do_test_apply_three_regions()
When CONFIG_DAMON_VADDR_KUNIT_TEST=y and making CONFIG_DEBUG_KMEMLEAK=y
and CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.
Since commit 9f86d624292c (&quot;mm/damon/vaddr-test: remove unnecessary
variables&quot;), the damon_destroy_ctx() is removed, but still call
damon_new_target() and damon_new_region(), the damon_region which is
allocated by kmem_cache_alloc() in damon_new_region() and the damon_target
which is allocated by kmalloc in damon_new_target() are not freed.  And
the damon_region which is allocated in damon_new_region() in
damon_set_regions() is also not freed.
So use damon_destroy_target to free all the damon_regions and damon_target.
    unreferenced object 0xffff888107c9a940 (size 64):
      comm &quot;kunit_try_catch&quot;, pid 1069, jiffies 4294670592 (age 732.761s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk
        60 c7 9c 07 81 88 ff ff f8 cb 9c 07 81 88 ff ff  `...............
      backtrace:
        [&lt;ffffffff817e0167&gt;] kmalloc_trace+0x27/0xa0
        [&lt;ffffffff819c11cf&gt;] damon_new_target+0x3f/0x1b0
        [&lt;ffffffff819c7d55&gt;] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
        [&lt;ffffffff819c82be&gt;] damon_test_apply_three_regions1+0x21e/0x260
        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90
        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380
        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70
        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20
    unreferenced object 0xffff8881079cc740 (size 56):
      comm &quot;kunit_try_catch&quot;, pid 1069, jiffies 4294670592 (age 732.761s)
      hex dump (first 32 bytes):
        05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................
        6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk
      backtrace:
        [&lt;ffffffff819bc492&gt;] damon_new_region+0x22/0x1c0
        [&lt;ffffffff819c7d91&gt;] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
        [&lt;ffffffff819c82be&gt;] damon_test_apply_three_regions1+0x21e/0x260
        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90
        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380
        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70
        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20
    unreferenced object 0xffff888107c9ac40 (size 64):
      comm &quot;kunit_try_catch&quot;, pid 1071, jiffies 4294670595 (age 732.843s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 06 00 00 00 6b 6b 6b 6b  ............kkkk
        a0 cc 9c 07 81 88 ff ff 78 a1 76 07 81 88 ff ff  ........x.v.....
      backtrace:
        [&lt;ffffffff817e0167&gt;] kmalloc_trace+0x27/0xa0
        [&lt;ffffffff819c11cf&gt;] damon_new_target+0x3f/0x1b0
        [&lt;ffffffff819c7d55&gt;] damon_do_test_apply_three_regions.constprop.0+0x95/0x3e0
        [&lt;ffffffff819c851e&gt;] damon_test_apply_three_regions2+0x21e/0x260
        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90
        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380
        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70
        [&lt;ffffffff81003791&gt;] ret_from_fork_asm+0x11/0x20
    unreferenced object 0xffff8881079ccc80 (size 56):
      comm &quot;kunit_try_catch&quot;, pid 1071, jiffies 4294670595 (age 732.843s)
      hex dump (first 32 bytes):
        05 00 00 00 00 00 00 00 14 00 00 00 00 00 00 00  ................
        6b 6b 6b 6b 6b 6b 6b 6b 00 00 00 00 6b 6b 6b 6b  kkkkkkkk....kkkk
      backtrace:
        [&lt;ffffffff819bc492&gt;] damon_new_region+0x22/0x1c0
        [&lt;ffffffff819c7d91&gt;] damon_do_test_apply_three_regions.constprop.0+0xd1/0x3e0
        [&lt;ffffffff819c851e&gt;] damon_test_apply_three_regions2+0x21e/0x260
        [&lt;ffffffff829fce6a&gt;] kunit_generic_run_threadfn_adapter+0x4a/0x90
        [&lt;ffffffff81237cf6&gt;] kthread+0x2b6/0x380
        [&lt;ffffffff81097add&gt;] ret_from_fork+0x2d/0x70
        [&lt;ffff
---truncated---
CVE-2023-52597:In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: fix setting of fpc register
kvm_arch_vcpu_ioctl_set_fpu() allows to set the floating point control
(fpc) register of a guest cpu. The new value is tested for validity by
temporarily loading it into the fpc register.
This may lead to corruption of the fpc register of the host process:
if an interrupt happens while the value is temporarily loaded into the fpc
register, and within interrupt context floating point or vector registers
are used, the current fp/vx registers are saved with save_fpu_regs()
assuming they belong to user space and will be loaded into fp/vx registers
when returning to user space.
test_fp_ctl() restores the original user space / host process fpc register
value, however it will be discarded, when returning to user space.
In result the host process will incorrectly continue to run with the value
that was supposed to be used for a guest cpu.
Fix this by simply removing the test. There is another test right before
the SIE context is entered which will handles invalid values.
This results in a change of behaviour: invalid values will now be accepted
instead of that the ioctl fails with -EINVAL. This seems to be acceptable,
given that this interface is most likely not used anymore, and this is in
addition the same behaviour implemented with the memory mapped interface
(replace invalid values with zero) - see sync_regs() in kvm-s390.c.
CVE-2023-52578:In the Linux kernel, the following vulnerability has been resolved:
net: bridge: use DEV_STATS_INC()
syzbot/KCSAN reported data-races in br_handle_frame_finish() [1]
This function can run from multiple cpus without mutual exclusion.
Adopt SMP safe DEV_STATS_INC() to update dev-&gt;stats fields.
Handles updates to dev-&gt;stats.tx_dropped while we are at it.
[1]
BUG: KCSAN: data-race in br_handle_frame_finish / br_handle_frame_finish
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1:
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
br_nf_hook_thresh+0x1ed/0x220
br_nf_pre_routing_finish_ipv6+0x50f/0x540
NF_HOOK include/linux/netfilter.h:304 [inline]
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
process_backlog+0x21f/0x380 net/core/dev.c:5965
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
napi_poll net/core/dev.c:6594 [inline]
net_rx_action+0x32b/0x750 net/core/dev.c:6727
__do_softirq+0xc1/0x265 kernel/softirq.c:553
run_ksoftirqd+0x17/0x20 kernel/softirq.c:921
smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164
kthread+0x1d7/0x210 kernel/kthread.c:388
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0:
br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189
br_nf_hook_thresh+0x1ed/0x220
br_nf_pre_routing_finish_ipv6+0x50f/0x540
NF_HOOK include/linux/netfilter.h:304 [inline]
br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178
br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508
nf_hook_entry_hookfn include/linux/netfilter.h:144 [inline]
nf_hook_bridge_pre net/bridge/br_input.c:272 [inline]
br_handle_frame+0x4c9/0x940 net/bridge/br_input.c:417
__netif_receive_skb_core+0xa8a/0x21e0 net/core/dev.c:5417
__netif_receive_skb_one_core net/core/dev.c:5521 [inline]
__netif_receive_skb+0x57/0x1b0 net/core/dev.c:5637
process_backlog+0x21f/0x380 net/core/dev.c:5965
__napi_poll+0x60/0x3b0 net/core/dev.c:6527
napi_poll net/core/dev.c:6594 [inline]
net_rx_action+0x32b/0x750 net/core/dev.c:6727
__do_softirq+0xc1/0x265 kernel/softirq.c:553
do_softirq+0x5e/0x90 kernel/softirq.c:454
__local_bh_enable_ip+0x64/0x70 kernel/softirq.c:381
__raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
_raw_spin_unlock_bh+0x36/0x40 kernel/locking/spinlock.c:210
spin_unlock_bh include/linux/spinlock.h:396 [inline]
batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356
batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560
process_one_work kernel/workqueue.c:2630 [inline]
process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703
worker_thread+0x525/0x730 kernel/workqueue.c:2784
kthread+0x1d7/0x210 kernel/kthread.c:388
ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304
value changed: 0x00000000000d7190 -&gt; 0x00000000000d7191
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 14848 Comm: kworker/u4:11 Not tainted 6.6.0-rc1-syzkaller-00236-gad8a69f361b9 #0
CVE-2023-52574:In the Linux kernel, the following vulnerability has been resolved:
team: fix null-ptr-deref when team device type is changed
Get a null-ptr-deref bug as follows with reproducer [1].
BUG: kernel NULL pointer dereference, address: 0000000000000228
...
RIP: 0010:vlan_dev_hard_header+0x35/0x140 [8021q]
...
Call Trace:
 &lt;TASK&gt;
 ? __die+0x24/0x70
 ? page_fault_oops+0x82/0x150
 ? exc_page_fault+0x69/0x150
 ? asm_exc_page_fault+0x26/0x30
 ? vlan_dev_hard_header+0x35/0x140 [8021q]
 ? vlan_dev_hard_header+0x8e/0x140 [8021q]
 neigh_connected_output+0xb2/0x100
 ip6_finish_output2+0x1cb/0x520
 ? nf_hook_slow+0x43/0xc0
 ? ip6_mtu+0x46/0x80
 ip6_finish_output+0x2a/0xb0
 mld_sendpack+0x18f/0x250
 mld_ifc_work+0x39/0x160
 process_one_work+0x1e6/0x3f0
 worker_thread+0x4d/0x2f0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe5/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
[1]
$ teamd -t team0 -d -c '{&quot;runner&quot;: {&quot;name&quot;: &quot;loadbalance&quot;}}'
$ ip link add name t-dummy type dummy
$ ip link add link t-dummy name t-dummy.100 type vlan id 100
$ ip link add name t-nlmon type nlmon
$ ip link set t-nlmon master team0
$ ip link set t-nlmon nomaster
$ ip link set t-dummy up
$ ip link set team0 up
$ ip link set t-dummy.100 down
$ ip link set t-dummy.100 master team0
When enslave a vlan device to team device and team device type is changed
from non-ether to ether, header_ops of team device is changed to
vlan_header_ops. That is incorrect and will trigger null-ptr-deref
for vlan-&gt;real_dev in vlan_dev_hard_header() because team device is not
a vlan device.
Cache eth_header_ops in team_setup(), then assign cached header_ops to
header_ops of team net device when its type is changed from non-ether
to ether to fix the bug.
CVE-2023-52595:In the Linux kernel, the following vulnerability has been resolved:
wifi: rt2x00: restart beacon queue when hardware reset
When a hardware reset is triggered, all registers are reset, so all
queues are forced to stop in hardware interface. However, mac80211
will not automatically stop the queue. If we don't manually stop the
beacon queue, the queue will be deadlocked and unable to start again.
This patch fixes the issue where Apple devices cannot connect to the
AP after calling ieee80211_restart_hw().
CVE-2024-26656:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix use-after-free bug
The bug can be triggered by sending a single amdgpu_gem_userptr_ioctl
to the AMDGPU DRM driver on any ASICs with an invalid address and size.
The bug was reported by Joonkyo Jung &lt;joonkyoj@yonsei.ac.kr&gt;.
For example the following code:
static void Syzkaller1(int fd)
{
	struct drm_amdgpu_gem_userptr arg;
	int ret;
	arg.addr = 0xffffffffffff0000;
	arg.size = 0x80000000; /*2 Gb*/
	arg.flags = 0x7;
	ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &amp;arg);
}
Due to the address and size are not valid there is a failure in
amdgpu_hmm_register-&gt;mmu_interval_notifier_insert-&gt;__mmu_interval_notifier_insert-&gt;
check_shl_overflow, but we even the amdgpu_hmm_register failure we still call
amdgpu_hmm_unregister into  amdgpu_gem_object_free which causes access to a bad address.
The following stack is below when the issue is reproduced when Kazan is enabled:
[  +0.000014] Hardware name: ASUS System Product Name/ROG STRIX B550-F GAMING (WI-FI), BIOS 1401 12/03/2020
[  +0.000009] RIP: 0010:mmu_interval_notifier_remove+0x327/0x340
[  +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
[  +0.000014] RSP: 0018:ffffc90002657988 EFLAGS: 00010246
[  +0.000013] RAX: 0000000000000000 RBX: 1ffff920004caf35 RCX: ffffffff8160565b
[  +0.000011] RDX: dffffc0000000000 RSI: 0000000000000004 RDI: ffff8881a9f78260
[  +0.000010] RBP: ffffc90002657a70 R08: 0000000000000001 R09: fffff520004caf25
[  +0.000010] R10: 0000000000000003 R11: ffffffff8161d1d6 R12: ffff88810e988c00
[  +0.000010] R13: ffff888126fb5a00 R14: ffff88810e988c0c R15: ffff8881a9f78260
[  +0.000011] FS:  00007ff9ec848540(0000) GS:ffff8883cc880000(0000) knlGS:0000000000000000
[  +0.000012] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000010] CR2: 000055b3f7e14328 CR3: 00000001b5770000 CR4: 0000000000350ef0
[  +0.000010] Call Trace:
[  +0.000006]  &lt;TASK&gt;
[  +0.000007]  ? show_regs+0x6a/0x80
[  +0.000018]  ? __warn+0xa5/0x1b0
[  +0.000019]  ? mmu_interval_notifier_remove+0x327/0x340
[  +0.000018]  ? report_bug+0x24a/0x290
[  +0.000022]  ? handle_bug+0x46/0x90
[  +0.000015]  ? exc_invalid_op+0x19/0x50
[  +0.000016]  ? asm_exc_invalid_op+0x1b/0x20
[  +0.000017]  ? kasan_save_stack+0x26/0x50
[  +0.000017]  ? mmu_interval_notifier_remove+0x23b/0x340
[  +0.000019]  ? mmu_interval_notifier_remove+0x327/0x340
[  +0.000019]  ? mmu_interval_notifier_remove+0x23b/0x340
[  +0.000020]  ? __pfx_mmu_interval_notifier_remove+0x10/0x10
[  +0.000017]  ? kasan_save_alloc_info+0x1e/0x30
[  +0.000018]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? __kasan_kmalloc+0xb1/0xc0
[  +0.000018]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? __kasan_check_read+0x11/0x20
[  +0.000020]  amdgpu_hmm_unregister+0x34/0x50 [amdgpu]
[  +0.004695]  amdgpu_gem_object_free+0x66/0xa0 [amdgpu]
[  +0.004534]  ? __pfx_amdgpu_gem_object_free+0x10/0x10 [amdgpu]
[  +0.004291]  ? do_syscall_64+0x5f/0xe0
[  +0.000023]  ? srso_return_thunk+0x5/0x5f
[  +0.000017]  drm_gem_object_free+0x3b/0x50 [drm]
[  +0.000489]  amdgpu_gem_userptr_ioctl+0x306/0x500 [amdgpu]
[  +0.004295]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[  +0.004270]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? __this_cpu_preempt_check+0x13/0x20
[  +0.000015]  ? srso_return_thunk+0x5/0x5f
[  +0.000013]  ? sysvec_apic_timer_interrupt+0x57/0xc0
[  +0.000020]  ? srso_return_thunk+0x5/0x5f
[  +0.000014]  ? asm_sysvec_apic_timer_interrupt+0x1b/0x20
[  +0.000022]  ? drm_ioctl_kernel+0x17b/0x1f0 [drm]
[  +0.000496]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[  +0.004272]  ? drm_ioctl_kernel+0x190/0x1f0 [drm]
[  +0.000492]  drm_ioctl_kernel+0x140/0x1f0 [drm]
[  +0.000497]  ? __pfx_amdgpu_gem_userptr_ioctl+0x10/0x10 [amdgpu]
[  +0.004297]  ? __pfx_drm_ioctl_kernel+0x10/0x10 [d
---truncated---
CVE-2023-52516:In the Linux kernel, the following vulnerability has been resolved:
dma-debug: don't call __dma_entry_alloc_check_leak() under free_entries_lock
__dma_entry_alloc_check_leak() calls into printk -&gt; serial console
output (qcom geni) and grabs port-&gt;lock under free_entries_lock
spin lock, which is a reverse locking dependency chain as qcom_geni
IRQ handler can call into dma-debug code and grab free_entries_lock
under port-&gt;lock.
Move __dma_entry_alloc_check_leak() call out of free_entries_lock
scope so that we don't acquire serial console's port-&gt;lock under it.
Trimmed-down lockdep splat:
 The existing dependency chain (in reverse order) is:
               -&gt; #2 (free_entries_lock){-.-.}-{2:2}:
        _raw_spin_lock_irqsave+0x60/0x80
        dma_entry_alloc+0x38/0x110
        debug_dma_map_page+0x60/0xf8
        dma_map_page_attrs+0x1e0/0x230
        dma_map_single_attrs.constprop.0+0x6c/0xc8
        geni_se_rx_dma_prep+0x40/0xcc
        qcom_geni_serial_isr+0x310/0x510
        __handle_irq_event_percpu+0x110/0x244
        handle_irq_event_percpu+0x20/0x54
        handle_irq_event+0x50/0x88
        handle_fasteoi_irq+0xa4/0xcc
        handle_irq_desc+0x28/0x40
        generic_handle_domain_irq+0x24/0x30
        gic_handle_irq+0xc4/0x148
        do_interrupt_handler+0xa4/0xb0
        el1_interrupt+0x34/0x64
        el1h_64_irq_handler+0x18/0x24
        el1h_64_irq+0x64/0x68
        arch_local_irq_enable+0x4/0x8
        ____do_softirq+0x18/0x24
        ...
               -&gt; #1 (&amp;port_lock_key){-.-.}-{2:2}:
        _raw_spin_lock_irqsave+0x60/0x80
        qcom_geni_serial_console_write+0x184/0x1dc
        console_flush_all+0x344/0x454
        console_unlock+0x94/0xf0
        vprintk_emit+0x238/0x24c
        vprintk_default+0x3c/0x48
        vprintk+0xb4/0xbc
        _printk+0x68/0x90
        register_console+0x230/0x38c
        uart_add_one_port+0x338/0x494
        qcom_geni_serial_probe+0x390/0x424
        platform_probe+0x70/0xc0
        really_probe+0x148/0x280
        __driver_probe_device+0xfc/0x114
        driver_probe_device+0x44/0x100
        __device_attach_driver+0x64/0xdc
        bus_for_each_drv+0xb0/0xd8
        __device_attach+0xe4/0x140
        device_initial_probe+0x1c/0x28
        bus_probe_device+0x44/0xb0
        device_add+0x538/0x668
        of_device_add+0x44/0x50
        of_platform_device_create_pdata+0x94/0xc8
        of_platform_bus_create+0x270/0x304
        of_platform_populate+0xac/0xc4
        devm_of_platform_populate+0x60/0xac
        geni_se_probe+0x154/0x160
        platform_probe+0x70/0xc0
        ...
               -&gt; #0 (console_owner){-...}-{0:0}:
        __lock_acquire+0xdf8/0x109c
        lock_acquire+0x234/0x284
        console_flush_all+0x330/0x454
        console_unlock+0x94/0xf0
        vprintk_emit+0x238/0x24c
        vprintk_default+0x3c/0x48
        vprintk+0xb4/0xbc
        _printk+0x68/0x90
        dma_entry_alloc+0xb4/0x110
        debug_dma_map_sg+0xdc/0x2f8
        __dma_map_sg_attrs+0xac/0xe4
        dma_map_sgtable+0x30/0x4c
        get_pages+0x1d4/0x1e4 [msm]
        msm_gem_pin_pages_locked+0x38/0xac [msm]
        msm_gem_pin_vma_locked+0x58/0x88 [msm]
        msm_ioctl_gem_submit+0xde4/0x13ac [msm]
        drm_ioctl_kernel+0xe0/0x15c
        drm_ioctl+0x2e8/0x3f4
        vfs_ioctl+0x30/0x50
        ...
 Chain exists of:
   console_owner --&gt; &amp;port_lock_key --&gt; free_entries_lock
  Possible unsafe locking scenario:
        CPU0                    CPU1
        ----                    ----
   lock(free_entries_lock);
                                lock(&amp;port_lock_key);
                                lock(free_entries_lock);
   lock(console_owner);
                *** DEADLOCK ***
 Call trace:
  dump_backtrace+0xb4/0xf0
  show_stack+0x20/0x30
  dump_stack_lvl+0x60/0x84
  dump_stack+0x18/0x24
  print_circular_bug+0x1cc/0x234
  check_noncircular+0x78/0xac
  __lock_acquire+0xdf8/0x109c
  lock_acquire+0x234/0x284
  console_flush_all+0x330/0x454
  consol
---truncated---
CVE-2023-52464:In the Linux kernel, the following vulnerability has been resolved:
EDAC/thunderx: Fix possible out-of-bounds string access
Enabling -Wstringop-overflow globally exposes a warning for a common bug
in the usage of strncat():
  drivers/edac/thunderx_edac.c: In function 'thunderx_ocx_com_threaded_isr':
  drivers/edac/thunderx_edac.c:1136:17: error: 'strncat' specified bound 1024 equals destination size [-Werror=stringop-overflow=]
   1136 |                 strncat(msg, other, OCX_MESSAGE_SIZE);
        |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
   ...
   1145 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);
   ...
   1150 |                                 strncat(msg, other, OCX_MESSAGE_SIZE);
   ...
Apparently the author of this driver expected strncat() to behave the
way that strlcat() does, which uses the size of the destination buffer
as its third argument rather than the length of the source buffer. The
result is that there is no check on the size of the allocated buffer.
Change it to strlcat().
  [ bp: Trim compiler output, fixup commit message. ]
CVE-2024-26759:In the Linux kernel, the following vulnerability has been resolved:
mm/swap: fix race when skipping swapcache
When skipping swapcache for SWP_SYNCHRONOUS_IO, if two or more threads
swapin the same entry at the same time, they get different pages (A, B). 
Before one thread (T0) finishes the swapin and installs page (A) to the
PTE, another thread (T1) could finish swapin of page (B), swap_free the
entry, then swap out the possibly modified page reusing the same entry. 
It breaks the pte_same check in (T0) because PTE value is unchanged,
causing ABA problem.  Thread (T0) will install a stalled page (A) into the
PTE and cause data corruption.
One possible callstack is like this:
CPU0                                 CPU1
----                                 ----
do_swap_page()                       do_swap_page() with same entry
&lt;direct swapin path&gt;                 &lt;direct swapin path&gt;
&lt;alloc page A&gt;                       &lt;alloc page B&gt;
swap_read_folio() &lt;- read to page A  swap_read_folio() &lt;- read to page B
&lt;slow on later locks or interrupt&gt;   &lt;finished swapin first&gt;
...                                  set_pte_at()
                                     swap_free() &lt;- entry is free
                                     &lt;write to page B, now page A stalled&gt;
                                     &lt;swap out page B to same swap entry&gt;
pte_same() &lt;- Check pass, PTE seems
              unchanged, but page A
              is stalled!
swap_free() &lt;- page B content lost!
set_pte_at() &lt;- staled page A installed!
And besides, for ZRAM, swap_free() allows the swap device to discard the
entry content, so even if page (B) is not modified, if swap_read_folio()
on CPU0 happens later than swap_free() on CPU1, it may also cause data
loss.
To fix this, reuse swapcache_prepare which will pin the swap entry using
the cache flag, and allow only one thread to swap it in, also prevent any
parallel code from putting the entry in the cache.  Release the pin after
PT unlocked.
Racers just loop and wait since it's a rare and very short event.  A
schedule_timeout_uninterruptible(1) call is added to avoid repeated page
faults wasting too much CPU, causing livelock or adding too much noise to
perf statistics.  A similar livelock issue was described in commit
029c4628b2eb (&quot;mm: swap: get rid of livelock in swapin readahead&quot;)
Reproducer:
This race issue can be triggered easily using a well constructed
reproducer and patched brd (with a delay in read path) [1]:
With latest 6.8 mainline, race caused data loss can be observed easily:
$ gcc -g -lpthread test-thread-swap-race.c &amp;&amp; ./a.out
  Polulating 32MB of memory region...
  Keep swapping out...
  Starting round 0...
  Spawning 65536 workers...
  32746 workers spawned, wait for done...
  Round 0: Error on 0x5aa00, expected 32746, got 32743, 3 data loss!
  Round 0: Error on 0x395200, expected 32746, got 32743, 3 data loss!
  Round 0: Error on 0x3fd000, expected 32746, got 32737, 9 data loss!
  Round 0 Failed, 15 data loss!
This reproducer spawns multiple threads sharing the same memory region
using a small swap device.  Every two threads updates mapped pages one by
one in opposite direction trying to create a race, with one dedicated
thread keep swapping out the data out using madvise.
The reproducer created a reproduce rate of about once every 5 minutes, so
the race should be totally possible in production.
After this patch, I ran the reproducer for over a few hundred rounds and
no data loss observed.
Performance overhead is minimal, microbenchmark swapin 10G from 32G
zram:
Before:     10934698 us
After:      11157121 us
Cached:     13155355 us (Dropping SWP_SYNCHRONOUS_IO flag)
[kasong@tencent.com: v4]
  Link: https://lkml.kernel.org/r/20240219082040.7495-1-ryncsn@gmail.com
CVE-2024-26751:In the Linux kernel, the following vulnerability has been resolved:
ARM: ep93xx: Add terminator to gpiod_lookup_table
Without the terminator, if a con_id is passed to gpio_find() that
does not exist in the lookup table the function will not stop looping
correctly, and eventually cause an oops.
CVE-2024-26778:In the Linux kernel, the following vulnerability has been resolved:
fbdev: savage: Error out if pixclock equals zero
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.
Although pixclock is checked in savagefb_decode_var(), but it is not
checked properly in savagefb_probe(). Fix this by checking whether
pixclock is zero in the function savagefb_check_var() before
info-&gt;var.pixclock is used as the divisor.
This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8.
CVE-2024-26772:In the Linux kernel, the following vulnerability has been resolved:
ext4: avoid allocating blocks from corrupted group in ext4_mb_find_by_goal()
Places the logic for checking if the group's block bitmap is corrupt under
the protection of the group lock to avoid allocating blocks from the group
with a corrupted block bitmap.
CVE-2023-52640:In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fix oob in ntfs_listxattr
The length of name cannot exceed the space occupied by ea.
CVE-2024-26695:In the Linux kernel, the following vulnerability has been resolved:
crypto: ccp - Fix null pointer dereference in __sev_platform_shutdown_locked
The SEV platform device can be shutdown with a null psp_master,
e.g., using DEBUG_TEST_DRIVER_REMOVE.  Found using KASAN:
[  137.148210] ccp 0000:23:00.1: enabling device (0000 -&gt; 0002)
[  137.162647] ccp 0000:23:00.1: no command queues available
[  137.170598] ccp 0000:23:00.1: sev enabled
[  137.174645] ccp 0000:23:00.1: psp enabled
[  137.178890] general protection fault, probably for non-canonical address 0xdffffc000000001e: 0000 [#1] PREEMPT SMP DEBUG_PAGEALLOC KASAN NOPTI
[  137.182693] KASAN: null-ptr-deref in range [0x00000000000000f0-0x00000000000000f7]
[  137.182693] CPU: 93 PID: 1 Comm: swapper/0 Not tainted 6.8.0-rc1+ #311
[  137.182693] RIP: 0010:__sev_platform_shutdown_locked+0x51/0x180
[  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
[  137.182693] RSP: 0018:ffffc900000cf9b0 EFLAGS: 00010216
[  137.182693] RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 000000000000001e
[  137.182693] RDX: 0000000000000000 RSI: 0000000000000008 RDI: 00000000000000f0
[  137.182693] RBP: ffffc900000cf9c8 R08: 0000000000000000 R09: fffffbfff58f5a66
[  137.182693] R10: ffffc900000cf9c8 R11: ffffffffac7ad32f R12: ffff8881e5052c28
[  137.182693] R13: ffff8881e5052c28 R14: ffff8881758e43e8 R15: ffffffffac64abf8
[  137.182693] FS:  0000000000000000(0000) GS:ffff889de7000000(0000) knlGS:0000000000000000
[  137.182693] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  137.182693] CR2: 0000000000000000 CR3: 0000001cf7c7e000 CR4: 0000000000350ef0
[  137.182693] Call Trace:
[  137.182693]  &lt;TASK&gt;
[  137.182693]  ? show_regs+0x6c/0x80
[  137.182693]  ? __die_body+0x24/0x70
[  137.182693]  ? die_addr+0x4b/0x80
[  137.182693]  ? exc_general_protection+0x126/0x230
[  137.182693]  ? asm_exc_general_protection+0x2b/0x30
[  137.182693]  ? __sev_platform_shutdown_locked+0x51/0x180
[  137.182693]  sev_firmware_shutdown.isra.0+0x1e/0x80
[  137.182693]  sev_dev_destroy+0x49/0x100
[  137.182693]  psp_dev_destroy+0x47/0xb0
[  137.182693]  sp_destroy+0xbb/0x240
[  137.182693]  sp_pci_remove+0x45/0x60
[  137.182693]  pci_device_remove+0xaa/0x1d0
[  137.182693]  device_remove+0xc7/0x170
[  137.182693]  really_probe+0x374/0xbe0
[  137.182693]  ? srso_return_thunk+0x5/0x5f
[  137.182693]  __driver_probe_device+0x199/0x460
[  137.182693]  driver_probe_device+0x4e/0xd0
[  137.182693]  __driver_attach+0x191/0x3d0
[  137.182693]  ? __pfx___driver_attach+0x10/0x10
[  137.182693]  bus_for_each_dev+0x100/0x190
[  137.182693]  ? __pfx_bus_for_each_dev+0x10/0x10
[  137.182693]  ? __kasan_check_read+0x15/0x20
[  137.182693]  ? srso_return_thunk+0x5/0x5f
[  137.182693]  ? _raw_spin_unlock+0x27/0x50
[  137.182693]  driver_attach+0x41/0x60
[  137.182693]  bus_add_driver+0x2a8/0x580
[  137.182693]  driver_register+0x141/0x480
[  137.182693]  __pci_register_driver+0x1d6/0x2a0
[  137.182693]  ? srso_return_thunk+0x5/0x5f
[  137.182693]  ? esrt_sysfs_init+0x1cd/0x5d0
[  137.182693]  ? __pfx_sp_mod_init+0x10/0x10
[  137.182693]  sp_pci_init+0x22/0x30
[  137.182693]  sp_mod_init+0x14/0x30
[  137.182693]  ? __pfx_sp_mod_init+0x10/0x10
[  137.182693]  do_one_initcall+0xd1/0x470
[  137.182693]  ? __pfx_do_one_initcall+0x10/0x10
[  137.182693]  ? parameq+0x80/0xf0
[  137.182693]  ? srso_return_thunk+0x5/0x5f
[  137.182693]  ? __kmalloc+0x3b0/0x4e0
[  137.182693]  ? kernel_init_freeable+0x92d/0x1050
[  137.182693]  ? kasan_populate_vmalloc_pte+0x171/0x190
[  137.182693]  ? srso_return_thunk+0x5/0x5f
[  137.182693]  kernel_init_freeable+0xa64/0x1050
[  137.182693]  ? __pfx_kernel_init+0x10/0x10
[  137.182693]  kernel_init+0x24/0x160
[  137.182693]  ? __switch_to_asm+0x3e/0x70
[  137.182693]  ret_from_fork+0x40/0x80
[  137.182693]  ? __pfx_kernel_init+0x1
---truncated---
CVE-2024-26736:In the Linux kernel, the following vulnerability has been resolved:
afs: Increase buffer size in afs_update_volume_status()
The max length of volume-&gt;vid value is 20 characters.
So increase idbuf[] size up to 24 to avoid overflow.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[DH: Actually, it's 20 + NUL, so increase it to 24 and use snprintf()]
CVE-2024-26777:In the Linux kernel, the following vulnerability has been resolved:
fbdev: sis: Error out if pixclock equals zero
The userspace program could pass any values to the driver through
ioctl() interface. If the driver doesn't check the value of pixclock,
it may cause divide-by-zero error.
In sisfb_check_var(), var-&gt;pixclock is used as a divisor to caculate
drate before it is checked against zero. Fix this by checking it
at the beginning.
This is similar to CVE-2022-3061 in i740fb which was fixed by
commit 15cf0b8.
CVE-2023-52598:In the Linux kernel, the following vulnerability has been resolved:
s390/ptrace: handle setting of fpc register correctly
If the content of the floating point control (fpc) register of a traced
process is modified with the ptrace interface the new value is tested for
validity by temporarily loading it into the fpc register.
This may lead to corruption of the fpc register of the tracing process:
if an interrupt happens while the value is temporarily loaded into the
fpc register, and within interrupt context floating point or vector
registers are used, the current fp/vx registers are saved with
save_fpu_regs() assuming they belong to user space and will be loaded into
fp/vx registers when returning to user space.
test_fp_ctl() restores the original user space fpc register value, however
it will be discarded, when returning to user space.
In result the tracer will incorrectly continue to run with the value that
was supposed to be used for the traced process.
Fix this by saving fpu register contents with save_fpu_regs() before using
test_fp_ctl().
CVE-2024-26771:In the Linux kernel, the following vulnerability has been resolved:
dmaengine: ti: edma: Add some null pointer checks to the edma_probe
devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
CVE-2023-52503:In the Linux kernel, the following vulnerability has been resolved:
tee: amdtee: fix use-after-free vulnerability in amdtee_close_session
There is a potential race condition in amdtee_close_session that may
cause use-after-free in amdtee_open_session. For instance, if a session
has refcount == 1, and one thread tries to free this session via:
    kref_put(&amp;sess-&gt;refcount, destroy_session);
the reference count will get decremented, and the next step would be to
call destroy_session(). However, if in another thread,
amdtee_open_session() is called before destroy_session() has completed
execution, alloc_session() may return 'sess' that will be freed up
later in destroy_session() leading to use-after-free in
amdtee_open_session.
To fix this issue, treat decrement of sess-&gt;refcount and removal of
'sess' from session list in destroy_session() as a critical section, so
that it is executed atomically.
CVE-2023-52493:In the Linux kernel, the following vulnerability has been resolved:
bus: mhi: host: Drop chan lock before queuing buffers
Ensure read and write locks for the channel are not taken in succession by
dropping the read lock from parse_xfer_event() such that a callback given
to client can potentially queue buffers and acquire the write lock in that
process. Any queueing of buffers should be done without channel read lock
acquired as it can result in multiple locks and a soft lockup.
[mani: added fixes tag and cc'ed stable]
CVE-2024-26795:In the Linux kernel, the following vulnerability has been resolved:
riscv: Sparse-Memory/vmemmap out-of-bounds fix
Offset vmemmap so that the first page of vmemmap will be mapped
to the first page of physical memory in order to ensure that
vmemmap’s bounds will be respected during
pfn_to_page()/page_to_pfn() operations.
The conversion macros will produce correct SV39/48/57 addresses
for every possible/valid DRAM_BASE inside the physical memory limits.
v2:Address Alex's comments
CVE-2023-52607:In the Linux kernel, the following vulnerability has been resolved:
powerpc/mm: Fix null-pointer dereference in pgtable_cache_add
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
CVE-2024-26615:In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix illegal rmb_desc access in SMC-D connection dump
A crash was found when dumping SMC-D connections. It can be reproduced
by following steps:
- run nginx/wrk test:
  smc_run nginx
  smc_run wrk -t 16 -c 1000 -d &lt;duration&gt; -H 'Connection: Close' &lt;URL&gt;
- continuously dump SMC-D connections in parallel:
  watch -n 1 'smcss -D'
 BUG: kernel NULL pointer dereference, address: 0000000000000030
 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G	E      6.7.0+ #55
 RIP: 0010:__smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
 Call Trace:
  &lt;TASK&gt;
  ? __die+0x24/0x70
  ? page_fault_oops+0x66/0x150
  ? exc_page_fault+0x69/0x140
  ? asm_exc_page_fault+0x26/0x30
  ? __smc_diag_dump.constprop.0+0x5e5/0x620 [smc_diag]
  ? __kmalloc_node_track_caller+0x35d/0x430
  ? __alloc_skb+0x77/0x170
  smc_diag_dump_proto+0xd0/0xf0 [smc_diag]
  smc_diag_dump+0x26/0x60 [smc_diag]
  netlink_dump+0x19f/0x320
  __netlink_dump_start+0x1dc/0x300
  smc_diag_handler_dump+0x6a/0x80 [smc_diag]
  ? __pfx_smc_diag_dump+0x10/0x10 [smc_diag]
  sock_diag_rcv_msg+0x121/0x140
  ? __pfx_sock_diag_rcv_msg+0x10/0x10
  netlink_rcv_skb+0x5a/0x110
  sock_diag_rcv+0x28/0x40
  netlink_unicast+0x22a/0x330
  netlink_sendmsg+0x1f8/0x420
  __sock_sendmsg+0xb0/0xc0
  ____sys_sendmsg+0x24e/0x300
  ? copy_msghdr_from_user+0x62/0x80
  ___sys_sendmsg+0x7c/0xd0
  ? __do_fault+0x34/0x160
  ? do_read_fault+0x5f/0x100
  ? do_fault+0xb0/0x110
  ? __handle_mm_fault+0x2b0/0x6c0
  __sys_sendmsg+0x4d/0x80
  do_syscall_64+0x69/0x180
  entry_SYSCALL_64_after_hwframe+0x6e/0x76
It is possible that the connection is in process of being established
when we dump it. Assumed that the connection has been registered in a
link group by smc_conn_create() but the rmb_desc has not yet been
initialized by smc_buf_create(), thus causing the illegal access to
conn-&gt;rmb_desc. So fix it by checking before dump.
CVE-2023-52491:In the Linux kernel, the following vulnerability has been resolved:
media: mtk-jpeg: Fix use after free bug due to error path handling in mtk_jpeg_dec_device_run
In mtk_jpeg_probe, &amp;jpeg-&gt;job_timeout_work is bound with
mtk_jpeg_job_timeout_work.
In mtk_jpeg_dec_device_run, if error happens in
mtk_jpeg_set_dec_dst, it will finally start the worker while
mark the job as finished by invoking v4l2_m2m_job_finish.
There are two methods to trigger the bug. If we remove the
module, it which will call mtk_jpeg_remove to make cleanup.
The possible sequence is as follows, which will cause a
use-after-free bug.
CPU0                  CPU1
mtk_jpeg_dec_...    |
  start worker	    |
                    |mtk_jpeg_job_timeout_work
mtk_jpeg_remove     |
  v4l2_m2m_release  |
    kfree(m2m_dev); |
                    |
                    | v4l2_m2m_get_curr_priv
                    |   m2m_dev-&gt;curr_ctx //use
If we close the file descriptor, which will call mtk_jpeg_release,
it will have a similar sequence.
Fix this bug by starting timeout worker only if started jpegdec worker
successfully. Then v4l2_m2m_job_finish will only be called in
either mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.
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.
CVE-2023-52617:In the Linux kernel, the following vulnerability has been resolved:
PCI: switchtec: Fix stdev_release() crash after surprise hot remove
A PCI device hot removal may occur while stdev-&gt;cdev is held open. The call
to stdev_release() then happens during close or exit, at a point way past
switchtec_pci_remove(). Otherwise the last ref would vanish with the
trailing put_device(), just before return.
At that later point in time, the devm cleanup has already removed the
stdev-&gt;mmio_mrpc mapping. Also, the stdev-&gt;pdev reference was not a counted
one. Therefore, in DMA mode, the iowrite32() in stdev_release() will cause
a fatal page fault, and the subsequent dma_free_coherent(), if reached,
would pass a stale &amp;stdev-&gt;pdev-&gt;dev pointer.
Fix by moving MRPC DMA shutdown into switchtec_pci_remove(), after
stdev_kill(). Counting the stdev-&gt;pdev ref is now optional, but may prevent
future accidents.
Reproducible via the script at
https://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com
CVE-2023-52608:In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Check mailbox/SMT channel for consistency
On reception of a completion interrupt the shared memory area is accessed
to retrieve the message header at first and then, if the message sequence
number identifies a transaction which is still pending, the related
payload is fetched too.
When an SCMI command times out the channel ownership remains with the
platform until eventually a late reply is received and, as a consequence,
any further transmission attempt remains pending, waiting for the channel
to be relinquished by the platform.
Once that late reply is received the channel ownership is given back
to the agent and any pending request is then allowed to proceed and
overwrite the SMT area of the just delivered late reply; then the wait
for the reply to the new request starts.
It has been observed that the spurious IRQ related to the late reply can
be wrongly associated with the freshly enqueued request: when that happens
the SCMI stack in-flight lookup procedure is fooled by the fact that the
message header now present in the SMT area is related to the new pending
transaction, even though the real reply has still to arrive.
This race-condition on the A2P channel can be detected by looking at the
channel status bits: a genuine reply from the platform will have set the
channel free bit before triggering the completion IRQ.
Add a consistency check to validate such condition in the A2P ISR.
CVE-2023-52498:In the Linux kernel, the following vulnerability has been resolved:
PM: sleep: Fix possible deadlocks in core system-wide PM code
It is reported that in low-memory situations the system-wide resume core
code deadlocks, because async_schedule_dev() executes its argument
function synchronously if it cannot allocate memory (and not only in
that case) and that function attempts to acquire a mutex that is already
held.  Executing the argument function synchronously from within
dpm_async_fn() may also be problematic for ordering reasons (it may
cause a consumer device's resume callback to be invoked before a
requisite supplier device's one, for example).
Address this by changing the code in question to use
async_schedule_dev_nocall() for scheduling the asynchronous
execution of device suspend and resume functions and to directly
run them synchronously if async_schedule_dev_nocall() returns false.
CVE-2021-47182:In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix scsi_mode_sense() buffer length handling
Several problems exist with scsi_mode_sense() buffer length handling:
 1) The allocation length field of the MODE SENSE(10) command is 16-bits,
    occupying bytes 7 and 8 of the CDB. With this command, access to mode
    pages larger than 255 bytes is thus possible. However, the CDB
    allocation length field is set by assigning len to byte 8 only, thus
    truncating buffer length larger than 255.
 2) If scsi_mode_sense() is called with len smaller than 8 with
    sdev-&gt;use_10_for_ms set, or smaller than 4 otherwise, the buffer length
    is increased to 8 and 4 respectively, and the buffer is zero filled
    with these increased values, thus corrupting the memory following the
    buffer.
Fix these 2 problems by using put_unaligned_be16() to set the allocation
length field of MODE SENSE(10) CDB and by returning an error when len is
too small.
Furthermore, if len is larger than 255B, always try MODE SENSE(10) first,
even if the device driver did not set sdev-&gt;use_10_for_ms. In case of
invalid opcode error for MODE SENSE(10), access to mode pages larger than
255 bytes are not retried using MODE SENSE(6). To avoid buffer length
overflows for the MODE_SENSE(10) case, check that len is smaller than 65535
bytes.
While at it, also fix the folowing:
 * Use get_unaligned_be16() to retrieve the mode data length and block
   descriptor length fields of the mode sense reply header instead of using
   an open coded calculation.
 * Fix the kdoc dbd argument explanation: the DBD bit stands for Disable
   Block Descriptor, which is the opposite of what the dbd argument
   description was.
CVE-2024-24861:A race condition was found in the Linux kernel'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.
CVE-2023-52492:In the Linux kernel, the following vulnerability has been resolved:
dmaengine: fix NULL pointer in channel unregistration function
__dma_async_device_channel_register() can fail. In case of failure,
chan-&gt;local is freed (with free_percpu()), and chan-&gt;local is nullified.
When dma_async_device_unregister() is called (because of managed API or
intentionally by DMA controller driver), channels are unconditionally
unregistered, leading to this NULL pointer:
[    1.318693] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000d0
[...]
[    1.484499] Call trace:
[    1.486930]  device_del+0x40/0x394
[    1.490314]  device_unregister+0x20/0x7c
[    1.494220]  __dma_async_device_channel_unregister+0x68/0xc0
Look at dma_async_device_register() function error path, channel device
unregistration is done only if chan-&gt;local is not NULL.
Then add the same condition at the beginning of
__dma_async_device_channel_unregister() function, to avoid NULL pointer
issue whatever the API used to reach this function.
CVE-2024-26764:In the Linux kernel, the following vulnerability has been resolved:
fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaio
If kiocb_set_cancel_fn() is called for I/O submitted via io_uring, the
following kernel warning appears:
WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8
Call trace:
 kiocb_set_cancel_fn+0x9c/0xa8
 ffs_epfile_read_iter+0x144/0x1d0
 io_read+0x19c/0x498
 io_issue_sqe+0x118/0x27c
 io_submit_sqes+0x25c/0x5fc
 __arm64_sys_io_uring_enter+0x104/0xab0
 invoke_syscall+0x58/0x11c
 el0_svc_common+0xb4/0xf4
 do_el0_svc+0x2c/0xb0
 el0_svc+0x2c/0xa4
 el0t_64_sync_handler+0x68/0xb4
 el0t_64_sync+0x1a4/0x1a8
Fix this by setting the IOCB_AIO_RW flag for read and write I/O that is
submitted by libaio.
CVE-2023-52441:In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix out of bounds in init_smb2_rsp_hdr()
If client send smb2 negotiate request and then send smb1 negotiate
request, init_smb2_rsp_hdr is called for smb1 negotiate request since
need_neg is set to false. This patch ignore smb1 packets after -&gt;need_neg
is set to false.
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.
CVE-2024-26885:In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix DEVMAP_HASH overflow check on 32-bit arches
The devmap code allocates a number hash buckets equal to the next power
of two of the max_entries value provided when creating the map. When
rounding up to the next power of two, the 32-bit variable storing the
number of buckets can overflow, and the code checks for overflow by
checking if the truncated 32-bit value is equal to 0. However, on 32-bit
arches the rounding up itself can overflow mid-way through, because it
ends up doing a left-shift of 32 bits on an unsigned long value. If the
size of an unsigned long is four bytes, this is undefined behaviour, so
there is no guarantee that we'll end up with a nice and tidy 0-value at
the end.
Syzbot managed to turn this into a crash on arm32 by creating a
DEVMAP_HASH with max_entries &gt; 0x80000000 and then trying to update it.
Fix this by moving the overflow check to before the rounding up
operation.
CVE-2024-26884:In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix hashtab overflow check on 32-bit arches
The hashtab code relies on roundup_pow_of_two() to compute the number of
hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code. So apply the same
fix to hashtab, by moving the overflow check to before the roundup.
CVE-2024-26883:In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix stackmap overflow check on 32-bit arches
The stackmap code relies on roundup_pow_of_two() to compute the number
of hash buckets, and contains an overflow check by checking if the
resulting value is 0. However, on 32-bit arches, the roundup code itself
can overflow by doing a 32-bit left-shift of an unsigned long value,
which is undefined behaviour, so it is not guaranteed to truncate
neatly. This was triggered by syzbot on the DEVMAP_HASH type, which
contains the same check, copied from the hashtab code.
The commit in the fixes tag actually attempted to fix this, but the fix
did not account for the UB, so the fix only works on CPUs where an
overflow does result in a neat truncation to zero, which is not
guaranteed. Checking the value before rounding does not have this
problem.
CVE-2024-26882:In the Linux kernel, the following vulnerability has been resolved:
net: ip_tunnel: make sure to pull inner header in ip_tunnel_rcv()
Apply the same fix than ones found in :
8d975c15c0cd (&quot;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()&quot;)
1ca1ba465e55 (&quot;geneve: make sure to pull inner header in geneve_rx()&quot;)
We have to save skb-&gt;network_header in a temporary variable
in order to be able to recompute the network_header pointer
after a pskb_inet_may_pull() call.
pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.
syzbot reported:
BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
 BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
 BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
 BUG: KMSAN: uninit-value in ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
  ip_tunnel_rcv+0xed9/0x2ed0 net/ipv4/ip_tunnel.c:409
  __ipgre_rcv+0x9bc/0xbc0 net/ipv4/ip_gre.c:389
  ipgre_rcv net/ipv4/ip_gre.c:411 [inline]
  gre_rcv+0x423/0x19f0 net/ipv4/ip_gre.c:447
  gre_rcv+0x2a4/0x390 net/ipv4/gre_demux.c:163
  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
  dst_input include/net/dst.h:461 [inline]
  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]
  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
  netif_receive_skb_internal net/core/dev.c:5734 [inline]
  netif_receive_skb+0x58/0x660 net/core/dev.c:5793
  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1556
  tun_get_user+0x53b9/0x66e0 drivers/net/tun.c:2009
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
  call_write_iter include/linux/fs.h:2087 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0xb6b/0x1520 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xd0 fs/read_write.c:652
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
  __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
  alloc_pages_mpol+0x62b/0x9d0 mm/mempolicy.c:2133
  alloc_pages+0x1be/0x1e0 mm/mempolicy.c:2204
  skb_page_frag_refill+0x2bf/0x7c0 net/core/sock.c:2909
  tun_build_skb drivers/net/tun.c:1686 [inline]
  tun_get_user+0xe0a/0x66e0 drivers/net/tun.c:1826
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2055
  call_write_iter include/linux/fs.h:2087 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0xb6b/0x1520 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xd0 fs/read_write.c:652
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CVE-2024-26817:In the Linux kernel, the following vulnerability has been resolved:
amdkfd: use calloc instead of kzalloc to avoid integer overflow
This uses calloc instead of doing the multiplication which might
overflow.
CVE-2021-47211:In the Linux kernel, the following vulnerability has been resolved:
ALSA: usb-audio: fix null pointer dereference on pointer cs_desc
The pointer cs_desc return from snd_usb_find_clock_source could
be null, so there is a potential null pointer dereference issue.
Fix this by adding a null check before dereference.
CVE-2024-26843:In the Linux kernel, the following vulnerability has been resolved:
efi: runtime: Fix potential overflow of soft-reserved region size
md_size will have been narrowed if we have &gt;= 4GB worth of pages in a
soft-reserved region.
CVE-2024-26840:In the Linux kernel, the following vulnerability has been resolved:
cachefiles: fix memory leak in cachefiles_add_cache()
The following memory leak was reported after unbinding /dev/cachefiles:
==================================================================
unreferenced object 0xffff9b674176e3c0 (size 192):
  comm &quot;cachefilesd2&quot;, pid 680, jiffies 4294881224
  hex dump (first 32 bytes):
    01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc ea38a44b):
    [&lt;ffffffff8eb8a1a5&gt;] kmem_cache_alloc+0x2d5/0x370
    [&lt;ffffffff8e917f86&gt;] prepare_creds+0x26/0x2e0
    [&lt;ffffffffc002eeef&gt;] cachefiles_determine_cache_security+0x1f/0x120
    [&lt;ffffffffc00243ec&gt;] cachefiles_add_cache+0x13c/0x3a0
    [&lt;ffffffffc0025216&gt;] cachefiles_daemon_write+0x146/0x1c0
    [&lt;ffffffff8ebc4a3b&gt;] vfs_write+0xcb/0x520
    [&lt;ffffffff8ebc5069&gt;] ksys_write+0x69/0xf0
    [&lt;ffffffff8f6d4662&gt;] do_syscall_64+0x72/0x140
    [&lt;ffffffff8f8000aa&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76
==================================================================
Put the reference count of cache_cred in cachefiles_daemon_unbind() to
fix the problem. And also put cache_cred in cachefiles_add_cache() error
branch to avoid memory leaks.
CVE-2024-26874:In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Fix a null pointer crash in mtk_drm_crtc_finish_page_flip
It's possible that mtk_crtc-&gt;event is NULL in
mtk_drm_crtc_finish_page_flip().
pending_needs_vblank value is set by mtk_crtc-&gt;event, but in
mtk_drm_crtc_atomic_flush(), it's is not guarded by the same
lock in mtk_drm_finish_page_flip(), thus a race condition happens.
Consider the following case:
CPU1                              CPU2
step 1:
mtk_drm_crtc_atomic_begin()
mtk_crtc-&gt;event is not null,
                                  step 1:
                                  mtk_drm_crtc_atomic_flush:
                                  mtk_drm_crtc_update_config(
                                      !!mtk_crtc-&gt;event)
step 2:
mtk_crtc_ddp_irq -&gt;
mtk_drm_finish_page_flip:
lock
mtk_crtc-&gt;event set to null,
pending_needs_vblank set to false
unlock
                                  pending_needs_vblank set to true,
                                  step 2:
                                  mtk_crtc_ddp_irq -&gt;
                                  mtk_drm_finish_page_flip called again,
                                  pending_needs_vblank is still true
                                  //null pointer
Instead of guarding the entire mtk_drm_crtc_atomic_flush(), it's more
efficient to just check if mtk_crtc-&gt;event is null before use.
CVE-2024-26900:In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev-&gt;serial
If kobject_add() is fail in bind_rdev_to_array(), 'rdev-&gt;serial' will be
alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152):
  comm &quot;mdadm&quot;, pid 789, jiffies 4294716910
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc f773277a):
    [&lt;0000000058b0a453&gt;] kmemleak_alloc+0x61/0xe0
    [&lt;00000000366adf14&gt;] __kmalloc_large_node+0x15e/0x270
    [&lt;000000002e82961b&gt;] __kmalloc_node.cold+0x11/0x7f
    [&lt;00000000f206d60a&gt;] kvmalloc_node+0x74/0x150
    [&lt;0000000034bf3363&gt;] rdev_init_serial+0x67/0x170
    [&lt;0000000010e08fe9&gt;] mddev_create_serial_pool+0x62/0x220
    [&lt;00000000c3837bf0&gt;] bind_rdev_to_array+0x2af/0x630
    [&lt;0000000073c28560&gt;] md_add_new_disk+0x400/0x9f0
    [&lt;00000000770e30ff&gt;] md_ioctl+0x15bf/0x1c10
    [&lt;000000006cfab718&gt;] blkdev_ioctl+0x191/0x3f0
    [&lt;0000000085086a11&gt;] vfs_ioctl+0x22/0x60
    [&lt;0000000018b656fe&gt;] __x64_sys_ioctl+0xba/0xe0
    [&lt;00000000e54e675e&gt;] do_syscall_64+0x71/0x150
    [&lt;000000008b0ad622&gt;] entry_SYSCALL_64_after_hwframe+0x6c/0x74
CVE-2024-26894:In the Linux kernel, the following vulnerability has been resolved:
ACPI: processor_idle: Fix memory leak in acpi_processor_power_exit()
After unregistering the CPU idle device, the memory associated with
it is not freed, leading to a memory leak:
unreferenced object 0xffff896282f6c000 (size 1024):
  comm &quot;swapper/0&quot;, pid 1, jiffies 4294893170
  hex dump (first 32 bytes):
    00 00 00 00 0b 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc 8836a742):
    [&lt;ffffffff993495ed&gt;] kmalloc_trace+0x29d/0x340
    [&lt;ffffffff9972f3b3&gt;] acpi_processor_power_init+0xf3/0x1c0
    [&lt;ffffffff9972d263&gt;] __acpi_processor_start+0xd3/0xf0
    [&lt;ffffffff9972d2bc&gt;] acpi_processor_start+0x2c/0x50
    [&lt;ffffffff99805872&gt;] really_probe+0xe2/0x480
    [&lt;ffffffff99805c98&gt;] __driver_probe_device+0x78/0x160
    [&lt;ffffffff99805daf&gt;] driver_probe_device+0x1f/0x90
    [&lt;ffffffff9980601e&gt;] __driver_attach+0xce/0x1c0
    [&lt;ffffffff99803170&gt;] bus_for_each_dev+0x70/0xc0
    [&lt;ffffffff99804822&gt;] bus_add_driver+0x112/0x210
    [&lt;ffffffff99807245&gt;] driver_register+0x55/0x100
    [&lt;ffffffff9aee4acb&gt;] acpi_processor_driver_init+0x3b/0xc0
    [&lt;ffffffff990012d1&gt;] do_one_initcall+0x41/0x300
    [&lt;ffffffff9ae7c4b0&gt;] kernel_init_freeable+0x320/0x470
    [&lt;ffffffff99b231f6&gt;] kernel_init+0x16/0x1b0
    [&lt;ffffffff99042e6d&gt;] ret_from_fork+0x2d/0x50
Fix this by freeing the CPU idle device after unregistering it.
CVE-2023-52642:In the Linux kernel, the following vulnerability has been resolved:
media: rc: bpf attach/detach requires write permission
Note that bpf attach/detach also requires CAP_NET_ADMIN.
CVE-2024-26839:In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Fix a memleak in init_credit_return
When dma_alloc_coherent fails to allocate dd-&gt;cr_base[i].va,
init_credit_return should deallocate dd-&gt;cr_base and
dd-&gt;cr_base[i] that allocated before. Or those resources
would be never freed and a memleak is triggered.
CVE-2024-26855:In the Linux kernel, the following vulnerability has been resolved:
net: ice: Fix potential NULL pointer dereference in ice_bridge_setlink()
The function ice_bridge_setlink() may encounter a NULL pointer dereference
if nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequently
in nla_for_each_nested(). To address this issue, add a check to ensure that
br_spec is not NULL before proceeding with the nested attribute iteration.
CVE-2024-26893:In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Fix double free in SMC transport cleanup path
When the generic SCMI code tears down a channel, it calls the chan_free
callback function, defined by each transport. Since multiple protocols
might share the same transport_info member, chan_free() might want to
clean up the same member multiple times within the given SCMI transport
implementation. In this case, it is SMC transport. This will lead to a NULL
pointer dereference at the second time:
    | scmi_protocol scmi_dev.1: Enabled polling mode TX channel - prot_id:16
    | arm-scmi firmware:scmi: SCMI Notifications - Core Enabled.
    | arm-scmi firmware:scmi: unable to communicate with SCMI
    | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
    | Mem abort info:
    |   ESR = 0x0000000096000004
    |   EC = 0x25: DABT (current EL), IL = 32 bits
    |   SET = 0, FnV = 0
    |   EA = 0, S1PTW = 0
    |   FSC = 0x04: level 0 translation fault
    | Data abort info:
    |   ISV = 0, ISS = 0x00000004, ISS2 = 0x00000000
    |   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
    |   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
    | user pgtable: 4k pages, 48-bit VAs, pgdp=0000000881ef8000
    | [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
    | Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP
    | Modules linked in:
    | CPU: 4 PID: 1 Comm: swapper/0 Not tainted 6.7.0-rc2-00124-g455ef3d016c9-dirty #793
    | Hardware name: FVP Base RevC (DT)
    | pstate: 61400009 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
    | pc : smc_chan_free+0x3c/0x6c
    | lr : smc_chan_free+0x3c/0x6c
    | Call trace:
    |  smc_chan_free+0x3c/0x6c
    |  idr_for_each+0x68/0xf8
    |  scmi_cleanup_channels.isra.0+0x2c/0x58
    |  scmi_probe+0x434/0x734
    |  platform_probe+0x68/0xd8
    |  really_probe+0x110/0x27c
    |  __driver_probe_device+0x78/0x12c
    |  driver_probe_device+0x3c/0x118
    |  __driver_attach+0x74/0x128
    |  bus_for_each_dev+0x78/0xe0
    |  driver_attach+0x24/0x30
    |  bus_add_driver+0xe4/0x1e8
    |  driver_register+0x60/0x128
    |  __platform_driver_register+0x28/0x34
    |  scmi_driver_init+0x84/0xc0
    |  do_one_initcall+0x78/0x33c
    |  kernel_init_freeable+0x2b8/0x51c
    |  kernel_init+0x24/0x130
    |  ret_from_fork+0x10/0x20
    | Code: f0004701 910a0021 aa1403e5 97b91c70 (b9400280)
    | ---[ end trace 0000000000000000 ]---
Simply check for the struct pointer being NULL before trying to access
its members, to avoid this situation.
This was found when a transport doesn't really work (for instance no SMC
service), the probe routines then tries to clean up, and triggers a crash.
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.
CVE-2021-47212:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Update error handler for UCTX and UMEM
In the fast unload flow, the device state is set to internal error,
which indicates that the driver started the destroy process.
In this case, when a destroy command is being executed, it should return
MLX5_CMD_STAT_OK.
Fix MLX5_CMD_OP_DESTROY_UCTX and MLX5_CMD_OP_DESTROY_UMEM to return OK
instead of EIO.
This fixes a call trace in the umem release process -
[ 2633.536695] Call Trace:
[ 2633.537518]  ib_uverbs_remove_one+0xc3/0x140 [ib_uverbs]
[ 2633.538596]  remove_client_context+0x8b/0xd0 [ib_core]
[ 2633.539641]  disable_device+0x8c/0x130 [ib_core]
[ 2633.540615]  __ib_unregister_device+0x35/0xa0 [ib_core]
[ 2633.541640]  ib_unregister_device+0x21/0x30 [ib_core]
[ 2633.542663]  __mlx5_ib_remove+0x38/0x90 [mlx5_ib]
[ 2633.543640]  auxiliary_bus_remove+0x1e/0x30 [auxiliary]
[ 2633.544661]  device_release_driver_internal+0x103/0x1f0
[ 2633.545679]  bus_remove_device+0xf7/0x170
[ 2633.546640]  device_del+0x181/0x410
[ 2633.547606]  mlx5_rescan_drivers_locked.part.10+0x63/0x160 [mlx5_core]
[ 2633.548777]  mlx5_unregister_device+0x27/0x40 [mlx5_core]
[ 2633.549841]  mlx5_uninit_one+0x21/0xc0 [mlx5_core]
[ 2633.550864]  remove_one+0x69/0xe0 [mlx5_core]
[ 2633.551819]  pci_device_remove+0x3b/0xc0
[ 2633.552731]  device_release_driver_internal+0x103/0x1f0
[ 2633.553746]  unbind_store+0xf6/0x130
[ 2633.554657]  kernfs_fop_write+0x116/0x190
[ 2633.555567]  vfs_write+0xa5/0x1a0
[ 2633.556407]  ksys_write+0x4f/0xb0
[ 2633.557233]  do_syscall_64+0x5b/0x1a0
[ 2633.558071]  entry_SYSCALL_64_after_hwframe+0x65/0xca
[ 2633.559018] RIP: 0033:0x7f9977132648
[ 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
[ 2633.562332] RSP: 002b:00007fffb1a83888 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[ 2633.563472] RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007f9977132648
[ 2633.564541] RDX: 000000000000000c RSI: 000055b90546e230 RDI: 0000000000000001
[ 2633.565596] RBP: 000055b90546e230 R08: 00007f9977406860 R09: 00007f9977a54740
[ 2633.566653] R10: 0000000000000000 R11: 0000000000000246 R12: 00007f99774056e0
[ 2633.567692] R13: 000000000000000c R14: 00007f9977400880 R15: 000000000000000c
[ 2633.568725] ---[ end trace 10b4fe52945e544d ]---
CVE-2024-26901:In the Linux kernel, the following vulnerability has been resolved:
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].
[1]
&quot;BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
 instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 _copy_to_user+0xbc/0x100 lib/usercopy.c:40
 copy_to_user include/linux/uaccess.h:191 [inline]
 do_sys_name_to_handle fs/fhandle.c:73 [inline]
 __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
 __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
 ...
Uninit was created at:
 slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
 slab_alloc_node mm/slub.c:3478 [inline]
 __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
 __do_kmalloc_node mm/slab_common.c:1006 [inline]
 __kmalloc+0x121/0x3c0 mm/slab_common.c:1020
 kmalloc include/linux/slab.h:604 [inline]
 do_sys_name_to_handle fs/fhandle.c:39 [inline]
 __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
 __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
 ...
Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240&quot;
Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem.
CVE-2024-26875:In the Linux kernel, the following vulnerability has been resolved:
media: pvrusb2: fix uaf in pvr2_context_set_notify
[Syzbot reported]
BUG: KASAN: slab-use-after-free in pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26
CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Workqueue: usb_hub_wq hub_event
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x1b0 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0xc4/0x620 mm/kasan/report.c:488
 kasan_report+0xda/0x110 mm/kasan/report.c:601
 pvr2_context_set_notify+0x2c4/0x310 drivers/media/usb/pvrusb2/pvrusb2-context.c:35
 pvr2_context_notify drivers/media/usb/pvrusb2/pvrusb2-context.c:95 [inline]
 pvr2_context_disconnect+0x94/0xb0 drivers/media/usb/pvrusb2/pvrusb2-context.c:272
Freed by task 906:
kasan_save_stack+0x33/0x50 mm/kasan/common.c:47
kasan_save_track+0x14/0x30 mm/kasan/common.c:68
kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640
poison_slab_object mm/kasan/common.c:241 [inline]
__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257
kasan_slab_free include/linux/kasan.h:184 [inline]
slab_free_hook mm/slub.c:2121 [inline]
slab_free mm/slub.c:4299 [inline]
kfree+0x105/0x340 mm/slub.c:4409
pvr2_context_check drivers/media/usb/pvrusb2/pvrusb2-context.c:137 [inline]
pvr2_context_thread_func+0x69d/0x960 drivers/media/usb/pvrusb2/pvrusb2-context.c:158
[Analyze]
Task A set disconnect_flag = !0, which resulted in Task B's condition being met
and releasing mp, leading to this issue.
[Fix]
Place the disconnect_flag assignment operation after all code in pvr2_context_disconnect()
to avoid this issue.
CVE-2022-48655:In the Linux kernel, the following vulnerability has been resolved:
firmware: arm_scmi: Harden accesses to the reset domains
Accessing reset domains descriptors by the index upon the SCMI drivers
requests through the SCMI reset operations interface can potentially
lead to out-of-bound violations if the SCMI driver misbehave.
Add an internal consistency check before any such domains descriptors
accesses.
CVE-2024-26898:In the Linux kernel, the following vulnerability has been resolved:
aoe: fix the potential use-after-free problem in aoecmd_cfg_pkts
This patch is against CVE-2023-6270. The description of cve is:
  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.
In aoecmd_cfg_pkts(), it always calls dev_put(ifp) when skb initial
code is finished. But the net_device ifp will still be used in
later tx()-&gt;dev_queue_xmit() in kthread. Which means that the
dev_put(ifp) should NOT be called in the success path of skb
initial code in aoecmd_cfg_pkts(). Otherwise tx() may run into
use-after-free because the net_device is freed.
This patch removed the dev_put(ifp) in the success path in
aoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().
CVE-2024-26669:In the Linux kernel, the following vulnerability has been resolved:
net/sched: flower: Fix chain template offload
When a qdisc is deleted from a net device the stack instructs the
underlying driver to remove its flow offload callback from the
associated filter block using the 'FLOW_BLOCK_UNBIND' command. The stack
then continues to replay the removal of the filters in the block for
this driver by iterating over the chains in the block and invoking the
'reoffload' operation of the classifier being used. In turn, the
classifier in its 'reoffload' operation prepares and emits a
'FLOW_CLS_DESTROY' command for each filter.
However, the stack does not do the same for chain templates and the
underlying driver never receives a 'FLOW_CLS_TMPLT_DESTROY' command when
a qdisc is deleted. This results in a memory leak [1] which can be
reproduced using [2].
Fix by introducing a 'tmplt_reoffload' operation and have the stack
invoke it with the appropriate arguments as part of the replay.
Implement the operation in the sole classifier that supports chain
templates (flower) by emitting the 'FLOW_CLS_TMPLT_{CREATE,DESTROY}'
command based on whether a flow offload callback is being bound to a
filter block or being unbound from one.
As far as I can tell, the issue happens since cited commit which
reordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()
in __tcf_block_put(). The order cannot be reversed as the filter block
is expected to be freed after flushing all the chains.
[1]
unreferenced object 0xffff888107e28800 (size 2048):
  comm &quot;tc&quot;, pid 1079, jiffies 4294958525 (age 3074.287s)
  hex dump (first 32 bytes):
    b1 a6 7c 11 81 88 ff ff e0 5b b3 10 81 88 ff ff  ..|......[......
    01 00 00 00 00 00 00 00 e0 aa b0 84 ff ff ff ff  ................
  backtrace:
    [&lt;ffffffff81c06a68&gt;] __kmem_cache_alloc_node+0x1e8/0x320
    [&lt;ffffffff81ab374e&gt;] __kmalloc+0x4e/0x90
    [&lt;ffffffff832aec6d&gt;] mlxsw_sp_acl_ruleset_get+0x34d/0x7a0
    [&lt;ffffffff832bc195&gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180
    [&lt;ffffffff832b2e1a&gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280
    [&lt;ffffffff83a10613&gt;] tc_setup_cb_call+0x183/0x340
    [&lt;ffffffff83a9f85a&gt;] fl_tmplt_create+0x3da/0x4c0
    [&lt;ffffffff83a22435&gt;] tc_ctl_chain+0xa15/0x1170
    [&lt;ffffffff838a863c&gt;] rtnetlink_rcv_msg+0x3cc/0xed0
    [&lt;ffffffff83ac87f0&gt;] netlink_rcv_skb+0x170/0x440
    [&lt;ffffffff83ac6270&gt;] netlink_unicast+0x540/0x820
    [&lt;ffffffff83ac6e28&gt;] netlink_sendmsg+0x8d8/0xda0
    [&lt;ffffffff83793def&gt;] ____sys_sendmsg+0x30f/0xa80
    [&lt;ffffffff8379d29a&gt;] ___sys_sendmsg+0x13a/0x1e0
    [&lt;ffffffff8379d50c&gt;] __sys_sendmsg+0x11c/0x1f0
    [&lt;ffffffff843b9ce0&gt;] do_syscall_64+0x40/0xe0
unreferenced object 0xffff88816d2c0400 (size 1024):
  comm &quot;tc&quot;, pid 1079, jiffies 4294958525 (age 3074.287s)
  hex dump (first 32 bytes):
    40 00 00 00 00 00 00 00 57 f6 38 be 00 00 00 00  @.......W.8.....
    10 04 2c 6d 81 88 ff ff 10 04 2c 6d 81 88 ff ff  ..,m......,m....
  backtrace:
    [&lt;ffffffff81c06a68&gt;] __kmem_cache_alloc_node+0x1e8/0x320
    [&lt;ffffffff81ab36c1&gt;] __kmalloc_node+0x51/0x90
    [&lt;ffffffff81a8ed96&gt;] kvmalloc_node+0xa6/0x1f0
    [&lt;ffffffff82827d03&gt;] bucket_table_alloc.isra.0+0x83/0x460
    [&lt;ffffffff82828d2b&gt;] rhashtable_init+0x43b/0x7c0
    [&lt;ffffffff832aed48&gt;] mlxsw_sp_acl_ruleset_get+0x428/0x7a0
    [&lt;ffffffff832bc195&gt;] mlxsw_sp_flower_tmplt_create+0x145/0x180
    [&lt;ffffffff832b2e1a&gt;] mlxsw_sp_flow_block_cb+0x1ea/0x280
    [&lt;ffffffff83a10613&gt;] tc_setup_cb_call+0x183/0x340
    [&lt;ffffffff83a9f85a&gt;] fl_tmplt_create+0x3da/0x4c0
    [&lt;ffffffff83a22435&gt;] tc_ctl_chain+0xa15/0x1170
    [&lt;ffffffff838a863c&gt;] rtnetlink_rcv_msg+0x3cc/0xed0
    [&lt;ffffffff83ac87f0&gt;] netlink_rcv_skb+0x170/0x440
    [&lt;ffffffff83ac6270&gt;] netlink_unicast+0x540/0x820
    [&lt;ffffffff83ac6e28&gt;] netlink_sendmsg+0x8d8/0xda0
    [&lt;ffffffff83793def&gt;] ____sys_sendmsg+0x30f/0xa80
[2]
 # tc qdisc add dev swp1 clsact
 # tc chain add dev swp1 ingress proto ip chain 1 flower dst_ip 0.0.0.0/32
 # tc qdisc del dev
---truncated---
CVE-2024-26680:In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: Fix DMA mapping for PTP hwts ring
Function aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytes
for PTP HWTS ring but then generic aq_ring_free() does not take this
into account.
Create and use a specific function to free HWTS ring to fix this
issue.
Trace:
[  215.351607] ------------[ cut here ]------------
[  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]
[  215.351635] WARNING: CPU: 33 PID: 10759 at kernel/dma/debug.c:988 check_unmap+0xa6f/0x2360
...
[  215.581176] Call Trace:
[  215.583632]  &lt;TASK&gt;
[  215.585745]  ? show_trace_log_lvl+0x1c4/0x2df
[  215.590114]  ? show_trace_log_lvl+0x1c4/0x2df
[  215.594497]  ? debug_dma_free_coherent+0x196/0x210
[  215.599305]  ? check_unmap+0xa6f/0x2360
[  215.603147]  ? __warn+0xca/0x1d0
[  215.606391]  ? check_unmap+0xa6f/0x2360
[  215.610237]  ? report_bug+0x1ef/0x370
[  215.613921]  ? handle_bug+0x3c/0x70
[  215.617423]  ? exc_invalid_op+0x14/0x50
[  215.621269]  ? asm_exc_invalid_op+0x16/0x20
[  215.625480]  ? check_unmap+0xa6f/0x2360
[  215.629331]  ? mark_lock.part.0+0xca/0xa40
[  215.633445]  debug_dma_free_coherent+0x196/0x210
[  215.638079]  ? __pfx_debug_dma_free_coherent+0x10/0x10
[  215.643242]  ? slab_free_freelist_hook+0x11d/0x1d0
[  215.648060]  dma_free_attrs+0x6d/0x130
[  215.651834]  aq_ring_free+0x193/0x290 [atlantic]
[  215.656487]  aq_ptp_ring_free+0x67/0x110 [atlantic]
...
[  216.127540] ---[ end trace 6467e5964dd2640b ]---
[  216.132160] DMA-API: Mapped at:
[  216.132162]  debug_dma_alloc_coherent+0x66/0x2f0
[  216.132165]  dma_alloc_attrs+0xf5/0x1b0
[  216.132168]  aq_ring_hwts_rx_alloc+0x150/0x1f0 [atlantic]
[  216.132193]  aq_ptp_ring_alloc+0x1bb/0x540 [atlantic]
[  216.132213]  aq_nic_init+0x4a1/0x760 [atlantic]
CVE-2024-26668:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_limit: reject configurations that cause integer overflow
Reject bogus configs where internal token counter wraps around.
This only occurs with very very large requests, such as 17gbyte/s.
Its better to reject this rather than having incorrect ratelimit.
CVE-2023-52620:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: disallow timeout for anonymous sets
Never used from userspace, disallow these parameters.
CVE-2024-27073:In the Linux kernel, the following vulnerability has been resolved:
media: ttpci: fix two memleaks in budget_av_attach
When saa7146_register_device and saa7146_vv_init fails, budget_av_attach
should free the resources it allocates, like the error-handling of
ttpci_budget_init does. Besides, there are two fixme comment refers to
such deallocations.
CVE-2024-27008:In the Linux kernel, the following vulnerability has been resolved:
drm: nv04: Fix out of bounds access
When Output Resource (dcb-&gt;or) value is assigned in
fabricate_dcb_output(), there may be out of bounds access to
dac_users array in case dcb-&gt;or is zero because ffs(dcb-&gt;or) is
used as index there.
The 'or' argument of fabricate_dcb_output() must be interpreted as a
number of bit to set, not value.
Utilize macros from 'enum nouveau_or' in calls instead of hardcoding.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-26958:In the Linux kernel, the following vulnerability has been resolved:
nfs: fix UAF in direct writes
In production we have been hitting the following warning consistently
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
WARNING: CPU: 17 PID: 1800359 at lib/refcount.c:28 refcount_warn_saturate+0x9c/0xe0
Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]
RIP: 0010:refcount_warn_saturate+0x9c/0xe0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __warn+0x9f/0x130
 ? refcount_warn_saturate+0x9c/0xe0
 ? report_bug+0xcc/0x150
 ? handle_bug+0x3d/0x70
 ? exc_invalid_op+0x16/0x40
 ? asm_exc_invalid_op+0x16/0x20
 ? refcount_warn_saturate+0x9c/0xe0
 nfs_direct_write_schedule_work+0x237/0x250 [nfs]
 process_one_work+0x12f/0x4a0
 worker_thread+0x14e/0x3b0
 ? ZSTD_getCParams_internal+0x220/0x220
 kthread+0xdc/0x120
 ? __btf_name_valid+0xa0/0xa0
 ret_from_fork+0x1f/0x30
This is because we're completing the nfs_direct_request twice in a row.
The source of this is when we have our commit requests to submit, we
process them and send them off, and then in the completion path for the
commit requests we have
if (nfs_commit_end(cinfo.mds))
	nfs_direct_write_complete(dreq);
However since we're submitting asynchronous requests we sometimes have
one that completes before we submit the next one, so we end up calling
complete on the nfs_direct_request twice.
The only other place we use nfs_generic_commit_list() is in
__nfs_commit_inode, which wraps this call in a
nfs_commit_begin();
nfs_commit_end();
Which is a common pattern for this style of completion handling, one
that is also repeated in the direct code with get_dreq()/put_dreq()
calls around where we process events as well as in the completion paths.
Fix this by using the same pattern for the commit requests.
Before with my 200 node rocksdb stress running this warning would pop
every 10ish minutes.  With my patch the stress test has been running for
several hours without popping.
CVE-2024-26972:In the Linux kernel, the following vulnerability has been resolved:
ubifs: ubifs_symlink: Fix memleak of inode-&gt;i_link in error path
For error handling path in ubifs_symlink(), inode will be marked as
bad first, then iput() is invoked. If inode-&gt;i_link is initialized by
fscrypt_encrypt_symlink() in encryption scenario, inode-&gt;i_link won't
be freed by callchain ubifs_free_inode -&gt; fscrypt_free_inode in error
handling path, because make_bad_inode() has changed 'inode-&gt;i_mode' as
'S_IFREG'.
Following kmemleak is easy to be reproduced by injecting error in
ubifs_jnl_update() when doing symlink in encryption scenario:
 unreferenced object 0xffff888103da3d98 (size 8):
  comm &quot;ln&quot;, pid 1692, jiffies 4294914701 (age 12.045s)
  backtrace:
   kmemdup+0x32/0x70
   __fscrypt_encrypt_symlink+0xed/0x1c0
   ubifs_symlink+0x210/0x300 [ubifs]
   vfs_symlink+0x216/0x360
   do_symlinkat+0x11a/0x190
   do_syscall_64+0x3b/0xe0
There are two ways fixing it:
 1. Remove make_bad_inode() in error handling path. We can do that
    because ubifs_evict_inode() will do same processes for good
    symlink inode and bad symlink inode, for inode-&gt;i_nlink checking
    is before is_bad_inode().
 2. Free inode-&gt;i_link before marking inode bad.
Method 2 is picked, it has less influence, personally, I think.
CVE-2024-26811:In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate payload size in ipc response
If installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipc
response to ksmbd kernel server. ksmbd should validate payload size of
ipc response from ksmbd.mountd to avoid memory overrun or
slab-out-of-bounds. This patch validate 3 ipc response that has payload.
CVE-2024-26828:In the Linux kernel, the following vulnerability has been resolved:
cifs: fix underflow in parse_server_interfaces()
In this loop, we step through the buffer and after each item we check
if the size_left is greater than the minimum size we need.  However,
the problem is that &quot;bytes_left&quot; is type ssize_t while sizeof() is type
size_t.  That means that because of type promotion, the comparison is
done as an unsigned and if we have negative bytes left the loop
continues instead of ending.
CVE-2024-26870:In the Linux kernel, the following vulnerability has been resolved:
NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102
A call to listxattr() with a buffer size = 0 returns the actual
size of the buffer needed for a subsequent call. When size &gt; 0,
nfs4_listxattr() does not return an error because either
generic_listxattr() or nfs4_listxattr_nfs4_label() consumes
exactly all the bytes then size is 0 when calling
nfs4_listxattr_nfs4_user() which then triggers the following
kernel BUG:
  [   99.403778] kernel BUG at mm/usercopy.c:102!
  [   99.404063] Internal error: Oops - BUG: 00000000f2000800 [#1] SMP
  [   99.408463] CPU: 0 PID: 3310 Comm: python3 Not tainted 6.6.0-61.fc40.aarch64 #1
  [   99.415827] Call trace:
  [   99.415985]  usercopy_abort+0x70/0xa0
  [   99.416227]  __check_heap_object+0x134/0x158
  [   99.416505]  check_heap_object+0x150/0x188
  [   99.416696]  __check_object_size.part.0+0x78/0x168
  [   99.416886]  __check_object_size+0x28/0x40
  [   99.417078]  listxattr+0x8c/0x120
  [   99.417252]  path_listxattr+0x78/0xe0
  [   99.417476]  __arm64_sys_listxattr+0x28/0x40
  [   99.417723]  invoke_syscall+0x78/0x100
  [   99.417929]  el0_svc_common.constprop.0+0x48/0xf0
  [   99.418186]  do_el0_svc+0x24/0x38
  [   99.418376]  el0_svc+0x3c/0x110
  [   99.418554]  el0t_64_sync_handler+0x120/0x130
  [   99.418788]  el0t_64_sync+0x194/0x198
  [   99.418994] Code: aa0003e3 d000a3e0 91310000 97f49bdb (d4210000)
Issue is reproduced when generic_listxattr() returns 'system.nfs4_acl',
thus calling lisxattr() with size = 16 will trigger the bug.
Add check on nfs4_listxattr() to return ERANGE error when it is
called with size &gt; 0 and the return value is greater than size.
CVE-2024-27059:In the Linux kernel, the following vulnerability has been resolved:
USB: usb-storage: Prevent divide-by-0 error in isd200_ata_command
The isd200 sub-driver in usb-storage uses the HEADS and SECTORS values
in the ATA ID information to calculate cylinder and head values when
creating a CDB for READ or WRITE commands.  The calculation involves
division and modulus operations, which will cause a crash if either of
these values is 0.  While this never happens with a genuine device, it
could happen with a flawed or subversive emulation, as reported by the
syzbot fuzzer.
Protect against this possibility by refusing to bind to the device if
either the ATA_ID_HEADS or ATA_ID_SECTORS value in the device's ID
information is 0.  This requires isd200_Initialization() to return a
negative error code when initialization fails; currently it always
returns 0 (even when there is an error).
CVE-2024-27043:In the Linux kernel, the following vulnerability has been resolved:
media: edia: dvbdev: fix a use-after-free
In dvb_register_device, *pdvbdev is set equal to dvbdev, which is freed
in several error-handling paths. However, *pdvbdev is not set to NULL
after dvbdev's deallocation, causing use-after-frees in many places,
for example, in the following call chain:
budget_register
  |-&gt; dvb_dmxdev_init
        |-&gt; dvb_register_device
  |-&gt; dvb_dmxdev_release
        |-&gt; dvb_unregister_device
              |-&gt; dvb_remove_device
                    |-&gt; dvb_device_put
                          |-&gt; kref_put
When calling dvb_unregister_device, dmxdev-&gt;dvbdev (i.e. *pdvbdev in
dvb_register_device) could point to memory that had been freed in
dvb_register_device. Thereafter, this pointer is transferred to
kref_put and triggering a use-after-free.
CVE-2024-26965:In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-msm8974: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
Only compile tested.
CVE-2024-26812:In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: Create persistent INTx handler
A vulnerability exists where the eventfd for INTx signaling can be
deconfigured, which unregisters the IRQ handler but still allows
eventfds to be signaled with a NULL context through the SET_IRQS ioctl
or through unmask irqfd if the device interrupt is pending.
Ideally this could be solved with some additional locking; the igate
mutex serializes the ioctl and config space accesses, and the interrupt
handler is unregistered relative to the trigger, but the irqfd path
runs asynchronous to those.  The igate mutex cannot be acquired from the
atomic context of the eventfd wake function.  Disabling the irqfd
relative to the eventfd registration is potentially incompatible with
existing userspace.
As a result, the solution implemented here moves configuration of the
INTx interrupt handler to track the lifetime of the INTx context object
and irq_type configuration, rather than registration of a particular
trigger eventfd.  Synchronization is added between the ioctl path and
eventfd_signal() wrapper such that the eventfd trigger can be
dynamically updated relative to in-flight interrupts or irqfd callbacks.
CVE-2024-26961:In the Linux kernel, the following vulnerability has been resolved:
mac802154: fix llsec key resources release in mac802154_llsec_key_del
mac802154_llsec_key_del() can free resources of a key directly without
following the RCU rules for waiting before the end of a grace period. This
may lead to use-after-free in case llsec_lookup_key() is traversing the
list of keys in parallel with a key deletion:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 4 PID: 16000 at lib/refcount.c:25 refcount_warn_saturate+0x162/0x2a0
Modules linked in:
CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014
RIP: 0010:refcount_warn_saturate+0x162/0x2a0
Call Trace:
 &lt;TASK&gt;
 llsec_lookup_key.isra.0+0x890/0x9e0
 mac802154_llsec_encrypt+0x30c/0x9c0
 ieee802154_subif_start_xmit+0x24/0x1e0
 dev_hard_start_xmit+0x13e/0x690
 sch_direct_xmit+0x2ae/0xbc0
 __dev_queue_xmit+0x11dd/0x3c20
 dgram_sendmsg+0x90b/0xd60
 __sys_sendto+0x466/0x4c0
 __x64_sys_sendto+0xe0/0x1c0
 do_syscall_64+0x45/0xf0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
Also, ieee802154_llsec_key_entry structures are not freed by
mac802154_llsec_key_del():
unreferenced object 0xffff8880613b6980 (size 64):
  comm &quot;iwpan&quot;, pid 2176, jiffies 4294761134 (age 60.475s)
  hex dump (first 32 bytes):
    78 0d 8f 18 80 88 ff ff 22 01 00 00 00 00 ad de  x.......&quot;.......
    00 00 00 00 00 00 00 00 03 00 cd ab 00 00 00 00  ................
  backtrace:
    [&lt;ffffffff81dcfa62&gt;] __kmem_cache_alloc_node+0x1e2/0x2d0
    [&lt;ffffffff81c43865&gt;] kmalloc_trace+0x25/0xc0
    [&lt;ffffffff88968b09&gt;] mac802154_llsec_key_add+0xac9/0xcf0
    [&lt;ffffffff8896e41a&gt;] ieee802154_add_llsec_key+0x5a/0x80
    [&lt;ffffffff8892adc6&gt;] nl802154_add_llsec_key+0x426/0x5b0
    [&lt;ffffffff86ff293e&gt;] genl_family_rcv_msg_doit+0x1fe/0x2f0
    [&lt;ffffffff86ff46d1&gt;] genl_rcv_msg+0x531/0x7d0
    [&lt;ffffffff86fee7a9&gt;] netlink_rcv_skb+0x169/0x440
    [&lt;ffffffff86ff1d88&gt;] genl_rcv+0x28/0x40
    [&lt;ffffffff86fec15c&gt;] netlink_unicast+0x53c/0x820
    [&lt;ffffffff86fecd8b&gt;] netlink_sendmsg+0x93b/0xe60
    [&lt;ffffffff86b91b35&gt;] ____sys_sendmsg+0xac5/0xca0
    [&lt;ffffffff86b9c3dd&gt;] ___sys_sendmsg+0x11d/0x1c0
    [&lt;ffffffff86b9c65a&gt;] __sys_sendmsg+0xfa/0x1d0
    [&lt;ffffffff88eadbf5&gt;] do_syscall_64+0x45/0xf0
    [&lt;ffffffff890000ea&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76
Handle the proper resource release in the RCU callback function
mac802154_llsec_key_del_rcu().
Note that if llsec_lookup_key() finds a key, it gets a refcount via
llsec_key_get() and locally copies key id from key_entry (which is a
list element). So it's safe to call llsec_key_put() and free the list
entry after the RCU grace period elapses.
Found by Linux Verification Center (linuxtesting.org).
CVE-2024-26931:In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix command flush on cable pull
System crash due to command failed to flush back to SCSI layer.
 BUG: unable to handle kernel NULL pointer dereference at 0000000000000000
 PGD 0 P4D 0
 Oops: 0000 [#1] SMP NOPTI
 CPU: 27 PID: 793455 Comm: kworker/u130:6 Kdump: loaded Tainted: G           OE    --------- -  - 4.18.0-372.9.1.el8.x86_64 #1
 Hardware name: HPE ProLiant DL360 Gen10/ProLiant DL360 Gen10, BIOS U32 09/03/2021
 Workqueue: nvme-wq nvme_fc_connect_ctrl_work [nvme_fc]
 RIP: 0010:__wake_up_common+0x4c/0x190
 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
 RSP: 0018:ffff95f3e0cb7cd0 EFLAGS: 00010086
 RAX: 0000000000000000 RBX: ffff8b08d3b26328 RCX: 0000000000000000
 RDX: 0000000000000001 RSI: 0000000000000003 RDI: ffff8b08d3b26320
 RBP: 0000000000000001 R08: 0000000000000000 R09: ffffffffffffffe8
 R10: 0000000000000000 R11: ffff95f3e0cb7a60 R12: ffff95f3e0cb7d20
 R13: 0000000000000003 R14: 0000000000000000 R15: 0000000000000000
 FS:  0000000000000000(0000) GS:ffff8b2fdf6c0000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000000000000000 CR3: 0000002f1e410002 CR4: 00000000007706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 PKRU: 55555554
 Call Trace:
  __wake_up_common_lock+0x7c/0xc0
  qla_nvme_ls_req+0x355/0x4c0 [qla2xxx]
 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
 ? __nvme_fc_send_ls_req+0x260/0x380 [nvme_fc]
 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:00:02:ac:07:ee:b8 state transitioned from ONLINE to LOST - portid=010200.
  ? nvme_fc_send_ls_req.constprop.42+0x1a/0x45 [nvme_fc]
 qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320002ac07eeb8. rport ffff8ae598122000 roles 1
 ? nvme_fc_connect_ctrl_work.cold.63+0x1e3/0xa7d [nvme_fc]
 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
  ? __switch_to+0x10c/0x450
 ? process_one_work+0x1a7/0x360
 qla2xxx [0000:12:00.1]-207d:3: FCPort 21:32:01:02:ad:f7:ee:b8 state transitioned from ONLINE to LOST - portid=010201.
  ? worker_thread+0x1ce/0x390
  ? create_worker+0x1a0/0x1a0
 qla2xxx [0000:12:00.1]-2109:3: qla2x00_schedule_rport_del 21320102adf7eeb8. rport ffff8ae3b2312800 roles 70
  ? kthread+0x10a/0x120
 qla2xxx [0000:12:00.1]-2112:3: qla_nvme_unregister_remote_port: unregister remoteport on ffff8ae14801e000 21320102adf7eeb8
  ? set_kthread_struct+0x40/0x40
 qla2xxx [0000:12:00.1]-2110:3: remoteport_delete of ffff8ae14801e000 21320102adf7eeb8 completed.
  ? ret_from_fork+0x1f/0x40
 qla2xxx [0000:12:00.1]-f086:3: qlt_free_session_done: waiting for sess ffff8ae14801e000 logout
The system was under memory stress where driver was not able to allocate an
SRB to carry out error recovery of cable pull.  The failure to flush causes
upper layer to start modifying scsi_cmnd.  When the system frees up some
memory, the subsequent cable pull trigger another command flush. At this
point the driver access a null pointer when attempting to DMA unmap the
SGL.
Add a check to make sure commands are flush back on session tear down to
prevent the null pointer access.
CVE-2023-52650:In the Linux kernel, the following vulnerability has been resolved:
drm/tegra: dsi: Add missing check for of_find_device_by_node
Add check for the return value of of_find_device_by_node() and return
the error if it fails in order to avoid NULL pointer dereference.
CVE-2024-26704:In the Linux kernel, the following vulnerability has been resolved:
ext4: fix double-free of blocks due to wrong extents moved_len
In ext4_move_extents(), moved_len is only updated when all moves are
successfully executed, and only discards orig_inode and donor_inode
preallocations when moved_len is not zero. When the loop fails to exit
after successfully moving some extents, moved_len is not updated and
remains at 0, so it does not discard the preallocations.
If the moved extents overlap with the preallocated extents, the
overlapped extents are freed twice in ext4_mb_release_inode_pa() and
ext4_process_freed_data() (as described in commit 94d7c16cbbbd (&quot;ext4:
Fix double-free of blocks with EXT4_IOC_MOVE_EXT&quot;)), and bb_free is
incremented twice. Hence when trim is executed, a zero-division bug is
triggered in mb_update_avg_fragment_size() because bb_free is not zero
and bb_fragments is zero.
Therefore, update move_len after each extent move to avoid the issue.
CVE-2024-26791:In the Linux kernel, the following vulnerability has been resolved:
btrfs: dev-replace: properly validate device names
There's a syzbot report that device name buffers passed to device
replace are not properly checked for string termination which could lead
to a read out of bounds in getname_kernel().
Add a helper that validates both source and target device name buffers.
For devid as the source initialize the buffer to empty string in case
something tries to read it later.
This was originally analyzed and fixed in a different way by Edward Adam
Davis (see links).
CVE-2024-26689:In the Linux kernel, the following vulnerability has been resolved:
ceph: prevent use-after-free in encode_cap_msg()
In fs/ceph/caps.c, in encode_cap_msg(), &quot;use after free&quot; error was
caught by KASAN at this line - 'ceph_buffer_get(arg-&gt;xattr_buf);'. This
implies before the refcount could be increment here, it was freed.
In same file, in &quot;handle_cap_grant()&quot; refcount is decremented by this
line - 'ceph_buffer_put(ci-&gt;i_xattrs.blob);'. It appears that a race
occurred and resource was freed by the latter line before the former
line could increment it.
encode_cap_msg() is called by __send_cap() and __send_cap() is called by
ceph_check_caps() after calling __prep_cap(). __prep_cap() is where
arg-&gt;xattr_buf is assigned to ci-&gt;i_xattrs.blob. This is the spot where
the refcount must be increased to prevent &quot;use after free&quot; error.
CVE-2024-26950:In the Linux kernel, the following vulnerability has been resolved:
wireguard: netlink: access device through ctx instead of peer
The previous commit fixed a bug that led to a NULL peer-&gt;device being
dereferenced. It's actually easier and faster performance-wise to
instead get the device from ctx-&gt;wg. This semantically makes more sense
too, since ctx-&gt;wg-&gt;peer_allowedips.seq is compared with
ctx-&gt;allowedips_seq, basing them both in ctx. This also acts as a
defence in depth provision against freed peers.
CVE-2024-27000:In the Linux kernel, the following vulnerability has been resolved:
serial: mxs-auart: add spinlock around changing cts state
The uart_handle_cts_change() function in serial_core expects the caller
to hold uport-&gt;lock. For example, I have seen the below kernel splat,
when the Bluetooth driver is loaded on an i.MX28 board.
    [   85.119255] ------------[ cut here ]------------
    [   85.124413] WARNING: CPU: 0 PID: 27 at /drivers/tty/serial/serial_core.c:3453 uart_handle_cts_change+0xb4/0xec
    [   85.134694] Modules linked in: hci_uart bluetooth ecdh_generic ecc wlcore_sdio configfs
    [   85.143314] CPU: 0 PID: 27 Comm: kworker/u3:0 Not tainted 6.6.3-00021-gd62a2f068f92 #1
    [   85.151396] Hardware name: Freescale MXS (Device Tree)
    [   85.156679] Workqueue: hci0 hci_power_on [bluetooth]
    (...)
    [   85.191765]  uart_handle_cts_change from mxs_auart_irq_handle+0x380/0x3f4
    [   85.198787]  mxs_auart_irq_handle from __handle_irq_event_percpu+0x88/0x210
    (...)
CVE-2024-26878:In the Linux kernel, the following vulnerability has been resolved:
quota: Fix potential NULL pointer dereference
Below race may cause NULL pointer dereference
P1					P2
dquot_free_inode			quota_off
					  drop_dquot_ref
					   remove_dquot_ref
					   dquots = i_dquot(inode)
  dquots = i_dquot(inode)
  srcu_read_lock
  dquots[cnt]) != NULL (1)
					     dquots[type] = NULL (2)
  spin_lock(&amp;dquots[cnt]-&gt;dq_dqb_lock) (3)
   ....
If dquot_free_inode(or other routines) checks inode's quota pointers (1)
before quota_off sets it to NULL(2) and use it (3) after that, NULL pointer
dereference will be triggered.
So let's fix it by using a temporary pointer to avoid this issue.
CVE-2024-27075:In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: avoid stack overflow warnings with clang
A previous patch worked around a KASAN issue in stv0367, now a similar
problem showed up with clang:
drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in 'stv0367ter_set_frontend' [-Werror,-Wframe-larger-than]
 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)
Rework the stv0367_writereg() function to be simpler and mark both
register access functions as noinline_for_stack so the temporary
i2c_msg structures do not get duplicated on the stack when KASAN_STACK
is enabled.
CVE-2024-27389:In the Linux kernel, the following vulnerability has been resolved:
pstore: inode: Only d_invalidate() is needed
Unloading a modular pstore backend with records in pstorefs would
trigger the dput() double-drop warning:
  WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410
Using the combo of d_drop()/dput() (as mentioned in
Documentation/filesystems/vfs.rst) isn't the right approach here, and
leads to the reference counting problem seen above. Use d_invalidate()
and update the code to not bother checking for error codes that can
never happen.
---
CVE-2024-26973:In the Linux kernel, the following vulnerability has been resolved:
fat: fix uninitialized field in nostale filehandles
When fat_encode_fh_nostale() encodes file handle without a parent it
stores only first 10 bytes of the file handle. However the length of the
file handle must be a multiple of 4 so the file handle is actually 12
bytes long and the last two bytes remain uninitialized. This is not
great at we potentially leak uninitialized information with the handle
to userspace. Properly initialize the full handle length.
CVE-2024-26993:In the Linux kernel, the following vulnerability has been resolved:
fs: sysfs: Fix reference leak in sysfs_break_active_protection()
The sysfs_break_active_protection() routine has an obvious reference
leak in its error path.  If the call to kernfs_find_and_get() fails then
kn will be NULL, so the companion sysfs_unbreak_active_protection()
routine won't get called (and would only cause an access violation by
trying to dereference kn-&gt;parent if it was called).  As a result, the
reference to kobj acquired at the start of the function will never be
released.
Fix the leak by adding an explicit kobject_put() call when kn is NULL.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2168</id>
		<title>An update for libreswan is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3652" id="CVE-2024-3652" title="CVE-2024-3652" type="cve"/>
		</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's default proposal handler causes an assertion failure and crashes and restarts. IKEv2 connections are not affected.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2169</id>
		<title>An update for libyaml is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3205" id="CVE-2024-3205" title="CVE-2024-3205" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2170</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20964" id="CVE-2024-20964" title="CVE-2024-20964" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20971" id="CVE-2024-20971" title="CVE-2024-20971" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20976" id="CVE-2024-20976" title="CVE-2024-20976" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20973" id="CVE-2024-20973" title="CVE-2024-20973" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20978" id="CVE-2024-20978" title="CVE-2024-20978" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20981" id="CVE-2024-20981" title="CVE-2024-20981" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20962" id="CVE-2024-20962" title="CVE-2024-20962" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20977" id="CVE-2024-20977" title="CVE-2024-20977" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20963" id="CVE-2024-20963" title="CVE-2024-20963" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20965" id="CVE-2024-20965" title="CVE-2024-20965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20972" id="CVE-2024-20972" title="CVE-2024-20972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20961" id="CVE-2024-20961" title="CVE-2024-20961" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20982" id="CVE-2024-20982" title="CVE-2024-20982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20970" id="CVE-2024-20970" title="CVE-2024-20970" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20967" id="CVE-2024-20967" title="CVE-2024-20967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20984" id="CVE-2024-20984" title="CVE-2024-20984" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20974" id="CVE-2024-20974" title="CVE-2024-20974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20966" id="CVE-2024-20966" title="CVE-2024-20966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20960" id="CVE-2024-20960" title="CVE-2024-20960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20985" id="CVE-2024-20985" title="CVE-2024-20985" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20969" id="CVE-2024-20969" title="CVE-2024-20969" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21000" id="CVE-2024-21000" title="CVE-2024-21000" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21069" id="CVE-2024-21069" title="CVE-2024-21069" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21009" id="CVE-2024-21009" title="CVE-2024-21009" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21087" id="CVE-2024-21087" title="CVE-2024-21087" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21047" id="CVE-2024-21047" title="CVE-2024-21047" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20998" id="CVE-2024-20998" title="CVE-2024-20998" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21013" id="CVE-2024-21013" title="CVE-2024-21013" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21060" id="CVE-2024-21060" title="CVE-2024-21060" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21008" id="CVE-2024-21008" title="CVE-2024-21008" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21102" id="CVE-2024-21102" title="CVE-2024-21102" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21054" id="CVE-2024-21054" title="CVE-2024-21054" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21062" id="CVE-2024-21062" title="CVE-2024-21062" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20994" id="CVE-2024-20994" title="CVE-2024-20994" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21096" id="CVE-2024-21096" title="CVE-2024-21096" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21061" id="CVE-2024-21061" title="CVE-2024-21061" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20993" id="CVE-2024-20993" title="CVE-2024-20993" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21055" id="CVE-2024-21055" title="CVE-2024-21055" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21057" id="CVE-2024-21057" title="CVE-2024-21057" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6129" id="CVE-2023-6129" title="CVE-2023-6129" type="cve"/>
		</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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
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).
CVE-2023-6129:Issue summary: The POLY1305 MAC (message authentication code) implementation
contains a bug that might corrupt the internal state of applications running
on PowerPC CPU based platforms if the CPU provides vector instructions.
Impact summary: If an attacker can influence whether the POLY1305 MAC
algorithm is used, the application state might be corrupted with various
application dependent consequences.
The POLY1305 MAC (message authentication code) implementation in OpenSSL for
PowerPC CPUs restores the contents of vector registers in a different order
than they are saved. Thus the contents of some of these vector registers
are corrupted when returning to the caller. The vulnerable code is used only
on newer PowerPC processors supporting the PowerISA 2.07 instructions.
The consequences of this kind of internal application state corruption can
be various - from no consequences, if the calling application does not
depend on the contents of non-volatile XMM registers at all, to the worst
consequences, where the attacker could get complete control of the application
process. However unless the compiler uses the vector registers for storing
pointers, the most likely consequence, if any, would be an incorrect result
of some application dependent calculations or a crash leading to a denial of
service.
The POLY1305 MAC algorithm is most frequently used as part of the
CHACHA20-POLY1305 AEAD (authenticated encryption with associated data)
algorithm. The most common usage of this AEAD cipher is with TLS protocol
versions 1.2 and 1.3. If this cipher is enabled on the server a malicious
client can influence whether this AEAD cipher is used. This implies that
TLS server applications using OpenSSL can be potentially impacted. However
we are currently not aware of any concrete application that would be affected
by this issue therefore we consider this a Low severity security issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2171</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6129" id="CVE-2023-6129" title="CVE-2023-6129" type="cve"/>
		</references>
		<description>CVE-2023-6129:Issue summary: The POLY1305 MAC (message authentication code) implementation
contains a bug that might corrupt the internal state of applications running
on PowerPC CPU based platforms if the CPU provides vector instructions.
Impact summary: If an attacker can influence whether the POLY1305 MAC
algorithm is used, the application state might be corrupted with various
application dependent consequences.
The POLY1305 MAC (message authentication code) implementation in OpenSSL for
PowerPC CPUs restores the contents of vector registers in a different order
than they are saved. Thus the contents of some of these vector registers
are corrupted when returning to the caller. The vulnerable code is used only
on newer PowerPC processors supporting the PowerISA 2.07 instructions.
The consequences of this kind of internal application state corruption can
be various - from no consequences, if the calling application does not
depend on the contents of non-volatile XMM registers at all, to the worst
consequences, where the attacker could get complete control of the application
process. However unless the compiler uses the vector registers for storing
pointers, the most likely consequence, if any, would be an incorrect result
of some application dependent calculations or a crash leading to a denial of
service.
The POLY1305 MAC algorithm is most frequently used as part of the
CHACHA20-POLY1305 AEAD (authenticated encryption with associated data)
algorithm. The most common usage of this AEAD cipher is with TLS protocol
versions 1.2 and 1.3. If this cipher is enabled on the server a malicious
client can influence whether this AEAD cipher is used. This implies that
TLS server applications using OpenSSL can be potentially impacted. However
we are currently not aware of any concrete application that would be affected
by this issue therefore we consider this a Low severity security issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2172</id>
		<title>An update for python-idna is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3651" id="CVE-2024-3651" title="CVE-2024-3651" type="cve"/>
		</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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2173</id>
		<title>An update for python-jinja2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34064" id="CVE-2024-34064" title="CVE-2024-34064" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2174</id>
		<title>An update for python-tqdm is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34062" id="CVE-2024-34062" title="CVE-2024-34062" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2175</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3447" id="CVE-2024-3447" title="CVE-2024-3447" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3446" id="CVE-2024-3446" title="CVE-2024-3446" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2176</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45935" id="CVE-2023-45935" title="CVE-2023-45935" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25580" id="CVE-2024-25580" title="CVE-2024-25580" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2177</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27282" id="CVE-2024-27282" title="CVE-2024-27282" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2178</id>
		<title>An update for sane-backends is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46047" id="CVE-2023-46047" title="CVE-2023-46047" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46052" id="CVE-2023-46052" title="CVE-2023-46052" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2179</id>
		<title>An update for skopeo is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28180" id="CVE-2024-28180" title="CVE-2024-28180" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29406" id="CVE-2023-29406" title="CVE-2023-29406" type="cve"/>
		</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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2180</id>
		<title>An update for sssd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3758" id="CVE-2023-3758" title="CVE-2023-3758" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2181</id>
		<title>An update for systemd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50387" id="CVE-2023-50387" title="CVE-2023-50387" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"/>
		</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 &quot;KeyTrap&quot; 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.
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 &quot;NSEC3&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="systemd" release="76.u17.fos23" version="249">
					<filename>systemd-249-76.u17.fos23.aarch64.rpm</filename>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2182</id>
		<title>An update for tcpdump is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2397" id="CVE-2024-2397" title="CVE-2024-2397" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2183</id>
		<title>An update for tpm2-tools is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29038" id="CVE-2024-29038" title="CVE-2024-29038" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29039" id="CVE-2024-29039" title="CVE-2024-29039" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2184</id>
		<title>An update for tpm2-tss is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29040" id="CVE-2024-29040" title="CVE-2024-29040" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2185</id>
		<title>An update for uriparser is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34402" id="CVE-2024-34402" title="CVE-2024-34402" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34403" id="CVE-2024-34403" title="CVE-2024-34403" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2186</id>
		<title>An update for webkit2gtk3 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-30294" id="CVE-2022-30294" title="CVE-2022-30294" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-05-22"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0229" id="CVE-2024-0229" title="CVE-2024-0229" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6377" id="CVE-2023-6377" title="CVE-2023-6377" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6478" id="CVE-2023-6478" title="CVE-2023-6478" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6816" id="CVE-2023-6816" title="CVE-2023-6816" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0408" id="CVE-2024-0408" title="CVE-2024-0408" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0409" id="CVE-2024-0409" title="CVE-2024-0409" type="cve"/>
		</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.
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.
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.
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's particular number of buttons, leading to a heap overflow if a bigger value was used.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2188</id>
		<title>An update for apache-poi is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-28"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26336" id="CVE-2022-26336" title="CVE-2022-26336" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2189</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-28"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48339" id="CVE-2022-48339" title="CVE-2022-48339" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2190</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-28"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39318" id="CVE-2023-39318" title="CVE-2023-39318" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39319" id="CVE-2023-39319" title="CVE-2023-39319" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39323" id="CVE-2023-39323" title="CVE-2023-39323" type="cve"/>
		</references>
		<description>CVE-2023-39318:The html/template package does not properly handle HTML-like &quot;&quot; comment tokens, nor hashbang &quot;#!&quot; 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.
CVE-2023-39319:The html/template package does not apply the proper rules for handling occurrences of &quot;&lt;script&quot;, &quot;&lt;!--&quot;, and &quot;&lt;/script&quot; 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.
CVE-2023-39323:Line directives (&quot;//line&quot;) can be used to bypass the restrictions on &quot;//go:cgo_&quot; directives, allowing blocked linker and compiler flags to be passed during compilation. This can result in unexpected execution of arbitrary code when running &quot;go build&quot;. 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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2191</id>
		<title>An update for gperftools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-28"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13420" id="CVE-2018-13420" title="CVE-2018-13420" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2192</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-28"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2002-20001" id="CVE-2002-20001" title="CVE-2002-20001" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2193</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-28"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2002-20001" id="CVE-2002-20001" title="CVE-2002-20001" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2194</id>
		<title>An update for tomcat is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-05-28"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25762" id="CVE-2022-25762" title="CVE-2022-25762" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2195</id>
		<title>An update for vim is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-05-28"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2426" id="CVE-2023-2426" title="CVE-2023-2426" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2196</id>
		<title>An update for giflib is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40633" id="CVE-2021-40633" title="CVE-2021-40633" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2197</id>
		<title>An update for git is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32004" id="CVE-2024-32004" title="CVE-2024-32004" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32020" id="CVE-2024-32020" title="CVE-2024-32020" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32021" id="CVE-2024-32021" title="CVE-2024-32021" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32465" id="CVE-2024-32465" title="CVE-2024-32465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32002" id="CVE-2024-32002" title="CVE-2024-32002" type="cve"/>
		</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.
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'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 &quot;proper&quot; 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.
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's `objects/` directory. When cloning a repository over the filesystem (without explicitly specifying the `file://` protocol or `--no-local`), the optimizations for local cloning
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.
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.
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'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't work. As always, it is best to avoid cloning repositories from untrusted sources.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2198</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24787" id="CVE-2024-24787" title="CVE-2024-24787" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24788" id="CVE-2024-24788" title="CVE-2024-24788" type="cve"/>
		</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 &quot;#cgo LDFLAGS&quot; directive.
CVE-2024-24788:A malformed DNS message in response to a query can cause the Lookup functions to get stuck in an 
infinite loop.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2199</id>
		<title>An update for infinispan is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10174" id="CVE-2019-10174" title="CVE-2019-10174" type="cve"/>
		</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's privileges. The attacker can use reflection to introduce new, malicious behavior into the application.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2200</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47193" id="CVE-2021-47193" title="CVE-2021-47193" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47199" id="CVE-2021-47199" title="CVE-2021-47199" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48645" id="CVE-2022-48645" title="CVE-2022-48645" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48673" id="CVE-2022-48673" title="CVE-2022-48673" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48674" id="CVE-2022-48674" title="CVE-2022-48674" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48703" id="CVE-2022-48703" title="CVE-2022-48703" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52434" id="CVE-2023-52434" title="CVE-2023-52434" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52444" id="CVE-2023-52444" title="CVE-2023-52444" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52457" id="CVE-2023-52457" title="CVE-2023-52457" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52610" id="CVE-2023-52610" title="CVE-2023-52610" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52612" id="CVE-2023-52612" title="CVE-2023-52612" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52614" id="CVE-2023-52614" title="CVE-2023-52614" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52627" id="CVE-2023-52627" title="CVE-2023-52627" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52646" id="CVE-2023-52646" title="CVE-2023-52646" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52652" id="CVE-2023-52652" title="CVE-2023-52652" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52686" id="CVE-2023-52686" title="CVE-2023-52686" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52753" id="CVE-2023-52753" title="CVE-2023-52753" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52802" id="CVE-2023-52802" title="CVE-2023-52802" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52806" id="CVE-2023-52806" title="CVE-2023-52806" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52814" id="CVE-2023-52814" title="CVE-2023-52814" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52817" id="CVE-2023-52817" title="CVE-2023-52817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52821" id="CVE-2023-52821" title="CVE-2023-52821" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52843" id="CVE-2023-52843" title="CVE-2023-52843" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52845" id="CVE-2023-52845" title="CVE-2023-52845" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52846" id="CVE-2023-52846" title="CVE-2023-52846" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52853" id="CVE-2023-52853" title="CVE-2023-52853" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52855" id="CVE-2023-52855" title="CVE-2023-52855" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52858" id="CVE-2023-52858" title="CVE-2023-52858" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52864" id="CVE-2023-52864" title="CVE-2023-52864" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52865" id="CVE-2023-52865" title="CVE-2023-52865" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52868" id="CVE-2023-52868" title="CVE-2023-52868" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52871" id="CVE-2023-52871" title="CVE-2023-52871" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52873" id="CVE-2023-52873" title="CVE-2023-52873" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52875" id="CVE-2023-52875" title="CVE-2023-52875" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52876" id="CVE-2023-52876" title="CVE-2023-52876" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24855" id="CVE-2024-24855" title="CVE-2024-24855" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26594" id="CVE-2024-26594" title="CVE-2024-26594" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26602" id="CVE-2024-26602" title="CVE-2024-26602" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26663" id="CVE-2024-26663" title="CVE-2024-26663" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26673" id="CVE-2024-26673" title="CVE-2024-26673" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26813" id="CVE-2024-26813" title="CVE-2024-26813" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26825" id="CVE-2024-26825" title="CVE-2024-26825" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26829" id="CVE-2024-26829" title="CVE-2024-26829" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26830" id="CVE-2024-26830" title="CVE-2024-26830" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26857" id="CVE-2024-26857" title="CVE-2024-26857" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26862" id="CVE-2024-26862" title="CVE-2024-26862" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26863" id="CVE-2024-26863" title="CVE-2024-26863" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26865" id="CVE-2024-26865" title="CVE-2024-26865" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26869" id="CVE-2024-26869" title="CVE-2024-26869" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26872" id="CVE-2024-26872" title="CVE-2024-26872" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26876" id="CVE-2024-26876" title="CVE-2024-26876" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26877" id="CVE-2024-26877" title="CVE-2024-26877" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26889" id="CVE-2024-26889" title="CVE-2024-26889" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26895" id="CVE-2024-26895" title="CVE-2024-26895" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26896" id="CVE-2024-26896" title="CVE-2024-26896" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26897" id="CVE-2024-26897" title="CVE-2024-26897" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26904" id="CVE-2024-26904" title="CVE-2024-26904" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26910" id="CVE-2024-26910" title="CVE-2024-26910" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26915" id="CVE-2024-26915" title="CVE-2024-26915" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26922" id="CVE-2024-26922" title="CVE-2024-26922" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26924" id="CVE-2024-26924" title="CVE-2024-26924" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26925" id="CVE-2024-26925" title="CVE-2024-26925" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26926" id="CVE-2024-26926" title="CVE-2024-26926" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26934" id="CVE-2024-26934" title="CVE-2024-26934" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26955" id="CVE-2024-26955" title="CVE-2024-26955" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26956" id="CVE-2024-26956" title="CVE-2024-26956" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26960" id="CVE-2024-26960" title="CVE-2024-26960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26966" id="CVE-2024-26966" title="CVE-2024-26966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26969" id="CVE-2024-26969" title="CVE-2024-26969" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26974" id="CVE-2024-26974" title="CVE-2024-26974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26979" id="CVE-2024-26979" title="CVE-2024-26979" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26981" id="CVE-2024-26981" title="CVE-2024-26981" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26984" id="CVE-2024-26984" title="CVE-2024-26984" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26988" id="CVE-2024-26988" title="CVE-2024-26988" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26994" id="CVE-2024-26994" title="CVE-2024-26994" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26996" id="CVE-2024-26996" title="CVE-2024-26996" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26999" id="CVE-2024-26999" title="CVE-2024-26999" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27001" id="CVE-2024-27001" title="CVE-2024-27001" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27004" id="CVE-2024-27004" title="CVE-2024-27004" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27010" id="CVE-2024-27010" title="CVE-2024-27010" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27011" id="CVE-2024-27011" title="CVE-2024-27011" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27014" id="CVE-2024-27014" title="CVE-2024-27014" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27019" id="CVE-2024-27019" title="CVE-2024-27019" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27020" id="CVE-2024-27020" title="CVE-2024-27020" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27028" id="CVE-2024-27028" title="CVE-2024-27028" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27030" id="CVE-2024-27030" title="CVE-2024-27030" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27032" id="CVE-2024-27032" title="CVE-2024-27032" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27034" id="CVE-2024-27034" title="CVE-2024-27034" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27035" id="CVE-2024-27035" title="CVE-2024-27035" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27037" id="CVE-2024-27037" title="CVE-2024-27037" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27038" id="CVE-2024-27038" title="CVE-2024-27038" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27046" id="CVE-2024-27046" title="CVE-2024-27046" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27051" id="CVE-2024-27051" title="CVE-2024-27051" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27053" id="CVE-2024-27053" title="CVE-2024-27053" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27054" id="CVE-2024-27054" title="CVE-2024-27054" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27074" id="CVE-2024-27074" title="CVE-2024-27074" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27077" id="CVE-2024-27077" title="CVE-2024-27077" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35935" id="CVE-2024-35935" title="CVE-2024-35935" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35973" id="CVE-2024-35973" title="CVE-2024-35973" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35978" id="CVE-2024-35978" title="CVE-2024-35978" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35982" id="CVE-2024-35982" title="CVE-2024-35982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35984" id="CVE-2024-35984" title="CVE-2024-35984" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35990" id="CVE-2024-35990" title="CVE-2024-35990" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36008" id="CVE-2024-36008" title="CVE-2024-36008" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36954" id="CVE-2024-36954" title="CVE-2024-36954" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47421" id="CVE-2021-47421" title="CVE-2021-47421" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47455" id="CVE-2021-47455" title="CVE-2021-47455" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48659" id="CVE-2022-48659" title="CVE-2022-48659" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48660" id="CVE-2022-48660" title="CVE-2022-48660" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48708" id="CVE-2022-48708" title="CVE-2022-48708" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52609" id="CVE-2023-52609" title="CVE-2023-52609" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52615" id="CVE-2023-52615" title="CVE-2023-52615" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52616" id="CVE-2023-52616" title="CVE-2023-52616" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52618" id="CVE-2023-52618" title="CVE-2023-52618" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52621" id="CVE-2023-52621" title="CVE-2023-52621" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52623" id="CVE-2023-52623" title="CVE-2023-52623" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52629" id="CVE-2023-52629" title="CVE-2023-52629" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52630" id="CVE-2023-52630" title="CVE-2023-52630" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52633" id="CVE-2023-52633" title="CVE-2023-52633" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52635" id="CVE-2023-52635" title="CVE-2023-52635" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52637" id="CVE-2023-52637" title="CVE-2023-52637" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52639" id="CVE-2023-52639" title="CVE-2023-52639" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52644" id="CVE-2023-52644" title="CVE-2023-52644" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52656" id="CVE-2023-52656" title="CVE-2023-52656" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52664" id="CVE-2023-52664" title="CVE-2023-52664" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52675" id="CVE-2023-52675" title="CVE-2023-52675" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52676" id="CVE-2023-52676" title="CVE-2023-52676" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52683" id="CVE-2023-52683" title="CVE-2023-52683" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52685" id="CVE-2023-52685" title="CVE-2023-52685" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52690" id="CVE-2023-52690" title="CVE-2023-52690" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52694" id="CVE-2023-52694" title="CVE-2023-52694" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52698" id="CVE-2023-52698" title="CVE-2023-52698" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52809" id="CVE-2023-52809" title="CVE-2023-52809" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52835" id="CVE-2023-52835" title="CVE-2023-52835" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52840" id="CVE-2023-52840" title="CVE-2023-52840" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52841" id="CVE-2023-52841" title="CVE-2023-52841" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52844" id="CVE-2023-52844" title="CVE-2023-52844" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52847" id="CVE-2023-52847" title="CVE-2023-52847" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52854" id="CVE-2023-52854" title="CVE-2023-52854" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52860" id="CVE-2023-52860" title="CVE-2023-52860" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52863" id="CVE-2023-52863" title="CVE-2023-52863" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52869" id="CVE-2023-52869" title="CVE-2023-52869" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52870" id="CVE-2023-52870" title="CVE-2023-52870" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24860" id="CVE-2024-24860" title="CVE-2024-24860" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26610" id="CVE-2024-26610" title="CVE-2024-26610" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26633" id="CVE-2024-26633" title="CVE-2024-26633" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26635" id="CVE-2024-26635" title="CVE-2024-26635" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26636" id="CVE-2024-26636" title="CVE-2024-26636" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26640" id="CVE-2024-26640" title="CVE-2024-26640" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26641" id="CVE-2024-26641" title="CVE-2024-26641" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26642" id="CVE-2024-26642" title="CVE-2024-26642" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26645" id="CVE-2024-26645" title="CVE-2024-26645" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26661" id="CVE-2024-26661" title="CVE-2024-26661" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26665" id="CVE-2024-26665" title="CVE-2024-26665" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26675" id="CVE-2024-26675" title="CVE-2024-26675" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26679" id="CVE-2024-26679" title="CVE-2024-26679" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26684" id="CVE-2024-26684" title="CVE-2024-26684" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26685" id="CVE-2024-26685" title="CVE-2024-26685" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26686" id="CVE-2024-26686" title="CVE-2024-26686" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26697" id="CVE-2024-26697" title="CVE-2024-26697" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26702" id="CVE-2024-26702" title="CVE-2024-26702" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26706" id="CVE-2024-26706" title="CVE-2024-26706" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26707" id="CVE-2024-26707" title="CVE-2024-26707" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26712" id="CVE-2024-26712" title="CVE-2024-26712" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26720" id="CVE-2024-26720" title="CVE-2024-26720" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26726" id="CVE-2024-26726" title="CVE-2024-26726" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26733" id="CVE-2024-26733" title="CVE-2024-26733" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26734" id="CVE-2024-26734" title="CVE-2024-26734" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26735" id="CVE-2024-26735" title="CVE-2024-26735" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26740" id="CVE-2024-26740" title="CVE-2024-26740" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26743" id="CVE-2024-26743" title="CVE-2024-26743" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26744" id="CVE-2024-26744" title="CVE-2024-26744" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26754" id="CVE-2024-26754" title="CVE-2024-26754" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26763" id="CVE-2024-26763" title="CVE-2024-26763" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26776" id="CVE-2024-26776" title="CVE-2024-26776" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26782" id="CVE-2024-26782" title="CVE-2024-26782" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26787" id="CVE-2024-26787" title="CVE-2024-26787" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26801" id="CVE-2024-26801" title="CVE-2024-26801" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26805" id="CVE-2024-26805" title="CVE-2024-26805" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26808" id="CVE-2024-26808" title="CVE-2024-26808" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26809" id="CVE-2024-26809" title="CVE-2024-26809" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26814" id="CVE-2024-26814" title="CVE-2024-26814" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26851" id="CVE-2024-26851" title="CVE-2024-26851" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26881" id="CVE-2024-26881" title="CVE-2024-26881" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26900" id="CVE-2024-26900" title="CVE-2024-26900" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26901" id="CVE-2024-26901" title="CVE-2024-26901" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26903" id="CVE-2024-26903" title="CVE-2024-26903" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26907" id="CVE-2024-26907" title="CVE-2024-26907" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26908" id="CVE-2024-26908" title="CVE-2024-26908" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26923" id="CVE-2024-26923" title="CVE-2024-26923" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26937" id="CVE-2024-26937" title="CVE-2024-26937" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26970" id="CVE-2024-26970" title="CVE-2024-26970" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26976" id="CVE-2024-26976" title="CVE-2024-26976" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26982" id="CVE-2024-26982" title="CVE-2024-26982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27002" id="CVE-2024-27002" title="CVE-2024-27002" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27072" id="CVE-2024-27072" title="CVE-2024-27072" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27395" id="CVE-2024-27395" title="CVE-2024-27395" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27396" id="CVE-2024-27396" title="CVE-2024-27396" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27398" id="CVE-2024-27398" title="CVE-2024-27398" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27401" id="CVE-2024-27401" title="CVE-2024-27401" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27407" id="CVE-2024-27407" title="CVE-2024-27407" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27419" id="CVE-2024-27419" title="CVE-2024-27419" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27426" id="CVE-2024-27426" title="CVE-2024-27426" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27427" id="CVE-2024-27427" title="CVE-2024-27427" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27431" id="CVE-2024-27431" title="CVE-2024-27431" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34459" id="CVE-2024-34459" title="CVE-2024-34459" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35791" id="CVE-2024-35791" title="CVE-2024-35791" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35801" id="CVE-2024-35801" title="CVE-2024-35801" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35805" id="CVE-2024-35805" title="CVE-2024-35805" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35806" id="CVE-2024-35806" title="CVE-2024-35806" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35807" id="CVE-2024-35807" title="CVE-2024-35807" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35818" id="CVE-2024-35818" title="CVE-2024-35818" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35835" id="CVE-2024-35835" title="CVE-2024-35835" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35844" id="CVE-2024-35844" title="CVE-2024-35844" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35845" id="CVE-2024-35845" title="CVE-2024-35845" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35848" id="CVE-2024-35848" title="CVE-2024-35848" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35849" id="CVE-2024-35849" title="CVE-2024-35849" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35898" id="CVE-2024-35898" title="CVE-2024-35898" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35922" id="CVE-2024-35922" title="CVE-2024-35922" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35934" id="CVE-2024-35934" title="CVE-2024-35934" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35936" id="CVE-2024-35936" title="CVE-2024-35936" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35938" id="CVE-2024-35938" title="CVE-2024-35938" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35940" id="CVE-2024-35940" title="CVE-2024-35940" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35943" id="CVE-2024-35943" title="CVE-2024-35943" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35997" id="CVE-2024-35997" title="CVE-2024-35997" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36006" id="CVE-2024-36006" title="CVE-2024-36006" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36039" id="CVE-2024-36039" title="CVE-2024-36039" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4853" id="CVE-2024-4853" title="CVE-2024-4853" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4855" id="CVE-2024-4855" title="CVE-2024-4855" type="cve"/>
		</references>
		<description>CVE-2021-47193:In the Linux kernel, the following vulnerability has been resolved:
scsi: pm80xx: Fix memory leak during rmmod
Driver failed to release all memory allocated. This would lead to memory
leak during driver removal.
Properly free memory when the module is removed.
CVE-2021-47199:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: CT, Fix multiple allocations and memleak of mod acts
CT clear action offload adds additional mod hdr actions to the
flow's original mod actions in order to clear the registers which
hold ct_state.
When such flow also includes encap action, a neigh update event
can cause the driver to unoffload the flow and then reoffload it.
Each time this happens, the ct clear handling adds that same set
of mod hdr actions to reset ct_state until the max of mod hdr
actions is reached.
Also the driver never releases the allocated mod hdr actions and
causing a memleak.
Fix above two issues by moving CT clear mod acts allocation
into the parsing actions phase and only use it when offloading the rule.
The release of mod acts will be done in the normal flow_put().
 backtrace:
    [&lt;000000007316e2f3&gt;] krealloc+0x83/0xd0
    [&lt;00000000ef157de1&gt;] mlx5e_mod_hdr_alloc+0x147/0x300 [mlx5_core]
    [&lt;00000000970ce4ae&gt;] mlx5e_tc_match_to_reg_set_and_get_id+0xd7/0x240 [mlx5_core]
    [&lt;0000000067c5fa17&gt;] mlx5e_tc_match_to_reg_set+0xa/0x20 [mlx5_core]
    [&lt;00000000d032eb98&gt;] mlx5_tc_ct_entry_set_registers.isra.0+0x36/0xc0 [mlx5_core]
    [&lt;00000000fd23b869&gt;] mlx5_tc_ct_flow_offload+0x272/0x1f10 [mlx5_core]
    [&lt;000000004fc24acc&gt;] mlx5e_tc_offload_fdb_rules.part.0+0x150/0x620 [mlx5_core]
    [&lt;00000000dc741c17&gt;] mlx5e_tc_encap_flows_add+0x489/0x690 [mlx5_core]
    [&lt;00000000e92e49d7&gt;] mlx5e_rep_update_flows+0x6e4/0x9b0 [mlx5_core]
    [&lt;00000000f60f5602&gt;] mlx5e_rep_neigh_update+0x39a/0x5d0 [mlx5_core]
CVE-2022-48645:In the Linux kernel, the following vulnerability has been resolved:
net: enetc: deny offload of tc-based TSN features on VF interfaces
TSN features on the ENETC (taprio, cbs, gate, police) are configured
through a mix of command BD ring messages and port registers:
enetc_port_rd(), enetc_port_wr().
Port registers are a region of the ENETC memory map which are only
accessible from the PCIe Physical Function. They are not accessible from
the Virtual Functions.
Moreover, attempting to access these registers crashes the kernel:
$ echo 1 &gt; /sys/bus/pci/devices/0000\:00\:00.0/sriov_numvfs
pci 0000:00:01.0: [1957:ef00] type 00 class 0x020001
fsl_enetc_vf 0000:00:01.0: Adding to iommu group 15
fsl_enetc_vf 0000:00:01.0: enabling device (0000 -&gt; 0002)
fsl_enetc_vf 0000:00:01.0 eno0vf0: renamed from eth0
$ tc qdisc replace dev eno0vf0 root taprio num_tc 8 map 0 1 2 3 4 5 6 7 \
	queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \
	sched-entry S 0x7f 900000 sched-entry S 0x80 100000 flags 0x2
Unable to handle kernel paging request at virtual address ffff800009551a08
Internal error: Oops: 96000007 [#1] PREEMPT SMP
pc : enetc_setup_tc_taprio+0x170/0x47c
lr : enetc_setup_tc_taprio+0x16c/0x47c
Call trace:
 enetc_setup_tc_taprio+0x170/0x47c
 enetc_setup_tc+0x38/0x2dc
 taprio_change+0x43c/0x970
 taprio_init+0x188/0x1e0
 qdisc_create+0x114/0x470
 tc_modify_qdisc+0x1fc/0x6c0
 rtnetlink_rcv_msg+0x12c/0x390
Split enetc_setup_tc() into separate functions for the PF and for the
VF drivers. Also remove enetc_qos.o from being included into
enetc-vf.ko, since it serves absolutely no purpose there.
CVE-2022-48673:In the Linux kernel, the following vulnerability has been resolved:
net/smc: Fix possible access to freed memory in link clear
After modifying the QP to the Error state, all RX WR would be completed
with WC in IB_WC_WR_FLUSH_ERR status. Current implementation does not
wait for it is done, but destroy the QP and free the link group directly.
So there is a risk that accessing the freed memory in tasklet context.
Here is a crash example:
 BUG: unable to handle page fault for address: ffffffff8f220860
 #PF: supervisor write access in kernel mode
 #PF: error_code(0x0002) - not-present page
 PGD f7300e067 P4D f7300e067 PUD f7300f063 PMD 8c4e45063 PTE 800ffff08c9df060
 Oops: 0002 [#1] SMP PTI
 CPU: 1 PID: 0 Comm: swapper/1 Kdump: loaded Tainted: G S         OE     5.10.0-0607+ #23
 Hardware name: Inspur NF5280M4/YZMB-00689-101, BIOS 4.1.20 07/09/2018
 RIP: 0010:native_queued_spin_lock_slowpath+0x176/0x1b0
 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
 RSP: 0018:ffffb3b6c001ebd8 EFLAGS: 00010086
 RAX: ffffffff8f220860 RBX: 0000000000000246 RCX: 0000000000080000
 RDX: ffff91db1f86c800 RSI: 000000000000173c RDI: ffff91db62bace00
 RBP: ffff91db62bacc00 R08: 0000000000000000 R09: c00000010000028b
 R10: 0000000000055198 R11: ffffb3b6c001ea58 R12: ffff91db80e05010
 R13: 000000000000000a R14: 0000000000000006 R15: 0000000000000040
 FS:  0000000000000000(0000) GS:ffff91db1f840000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: ffffffff8f220860 CR3: 00000001f9580004 CR4: 00000000003706e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;IRQ&gt;
  _raw_spin_lock_irqsave+0x30/0x40
  mlx5_ib_poll_cq+0x4c/0xc50 [mlx5_ib]
  smc_wr_rx_tasklet_fn+0x56/0xa0 [smc]
  tasklet_action_common.isra.21+0x66/0x100
  __do_softirq+0xd5/0x29c
  asm_call_irq_on_stack+0x12/0x20
  &lt;/IRQ&gt;
  do_softirq_own_stack+0x37/0x40
  irq_exit_rcu+0x9d/0xa0
  sysvec_call_function_single+0x34/0x80
  asm_sysvec_call_function_single+0x12/0x20
CVE-2022-48674:In the Linux kernel, the following vulnerability has been resolved:
erofs: fix pcluster use-after-free on UP platforms
During stress testing with CONFIG_SMP disabled, KASAN reports as below:
==================================================================
BUG: KASAN: use-after-free in __mutex_lock+0xe5/0xc30
Read of size 8 at addr ffff8881094223f8 by task stress/7789
CPU: 0 PID: 7789 Comm: stress Not tainted 6.0.0-rc1-00002-g0d53d2e882f9 #3
Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
Call Trace:
 &lt;TASK&gt;
..
 __mutex_lock+0xe5/0xc30
..
 z_erofs_do_read_page+0x8ce/0x1560
..
 z_erofs_readahead+0x31c/0x580
..
Freed by task 7787
 kasan_save_stack+0x1e/0x40
 kasan_set_track+0x20/0x30
 kasan_set_free_info+0x20/0x40
 __kasan_slab_free+0x10c/0x190
 kmem_cache_free+0xed/0x380
 rcu_core+0x3d5/0xc90
 __do_softirq+0x12d/0x389
Last potentially related work creation:
 kasan_save_stack+0x1e/0x40
 __kasan_record_aux_stack+0x97/0xb0
 call_rcu+0x3d/0x3f0
 erofs_shrink_workstation+0x11f/0x210
 erofs_shrink_scan+0xdc/0x170
 shrink_slab.constprop.0+0x296/0x530
 drop_slab+0x1c/0x70
 drop_caches_sysctl_handler+0x70/0x80
 proc_sys_call_handler+0x20a/0x2f0
 vfs_write+0x555/0x6c0
 ksys_write+0xbe/0x160
 do_syscall_64+0x3b/0x90
The root cause is that erofs_workgroup_unfreeze() doesn't reset to
orig_val thus it causes a race that the pcluster reuses unexpectedly
before freeing.
Since UP platforms are quite rare now, such path becomes unnecessary.
Let's drop such specific-designed path directly instead.
CVE-2022-48703:In the Linux kernel, the following vulnerability has been resolved:
thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTR
In some case, the GDDV returns a package with a buffer which has
zero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).
Then the data_vault_read() got NULL point dereference problem when
accessing the 0x10 value in data_vault.
[   71.024560] BUG: kernel NULL pointer dereference, address:
0000000000000010
This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR or
NULL value in data_vault.
CVE-2023-52434:In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential OOBs in smb2_parse_contexts()
Validate offsets and lengths before dereferencing create contexts in
smb2_parse_contexts().
This fixes following oops when accessing invalid create contexts from
server:
  BUG: unable to handle page fault for address: ffff8881178d8cc3
  #PF: supervisor read access in kernel mode
  #PF: error_code(0x0000) - not-present page
  PGD 4a01067 P4D 4a01067 PUD 0
  Oops: 0000 [#1] PREEMPT SMP NOPTI
  CPU: 3 PID: 1736 Comm: mount.cifs Not tainted 6.7.0-rc4 #1
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS
  rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014
  RIP: 0010:smb2_parse_contexts+0xa0/0x3a0 [cifs]
  Code: f8 10 75 13 48 b8 93 ad 25 50 9c b4 11 e7 49 39 06 0f 84 d2 00
  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
  7d 04 0f b7 45 06 4c 8d 74 3d 00 66 83 f8 04 75 bc ba 04 00
  RSP: 0018:ffffc900007939e0 EFLAGS: 00010216
  RAX: ffffc90000793c78 RBX: ffff8880180cc000 RCX: ffffc90000793c90
  RDX: ffffc90000793cc0 RSI: ffff8880178d8cc0 RDI: ffff8880180cc000
  RBP: ffff8881178d8cbf R08: ffffc90000793c22 R09: 0000000000000000
  R10: ffff8880180cc000 R11: 0000000000000024 R12: 0000000000000000
  R13: 0000000000000020 R14: 0000000000000000 R15: ffffc90000793c22
  FS: 00007f873753cbc0(0000) GS:ffff88806bc00000(0000)
  knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: ffff8881178d8cc3 CR3: 00000000181ca000 CR4: 0000000000750ef0
  PKRU: 55555554
  Call Trace:
   &lt;TASK&gt;
   ? __die+0x23/0x70
   ? page_fault_oops+0x181/0x480
   ? search_module_extables+0x19/0x60
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? exc_page_fault+0x1b6/0x1c0
   ? asm_exc_page_fault+0x26/0x30
   ? smb2_parse_contexts+0xa0/0x3a0 [cifs]
   SMB2_open+0x38d/0x5f0 [cifs]
   ? smb2_is_path_accessible+0x138/0x260 [cifs]
   smb2_is_path_accessible+0x138/0x260 [cifs]
   cifs_is_path_remote+0x8d/0x230 [cifs]
   cifs_mount+0x7e/0x350 [cifs]
   cifs_smb3_do_mount+0x128/0x780 [cifs]
   smb3_get_tree+0xd9/0x290 [cifs]
   vfs_get_tree+0x2c/0x100
   ? capable+0x37/0x70
   path_mount+0x2d7/0xb80
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? _raw_spin_unlock_irqrestore+0x44/0x60
   __x64_sys_mount+0x11a/0x150
   do_syscall_64+0x47/0xf0
   entry_SYSCALL_64_after_hwframe+0x6f/0x77
  RIP: 0033:0x7f8737657b1e
CVE-2023-52444:In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid dirent corruption
As Al reported in link[1]:
f2fs_rename()
...
	if (old_dir != new_dir &amp;&amp; !whiteout)
		f2fs_set_link(old_inode, old_dir_entry,
					old_dir_page, new_dir);
	else
		f2fs_put_page(old_dir_page, 0);
You want correct inumber in the &quot;..&quot; link.  And cross-directory
rename does move the source to new parent, even if you'd been asked
to leave a whiteout in the old place.
[1] https://lore.kernel.org/all/20231017055040.GN800259@ZenIV/
With below testcase, it may cause dirent corruption, due to it missed
to call f2fs_set_link() to update &quot;..&quot; link to new directory.
- mkdir -p dir/foo
- renameat2 -w dir/foo bar
[ASSERT] (__chk_dots_dentries:1421)  --&gt; Bad inode number[0x4] for '..', parent parent ino is [0x3]
[FSCK] other corrupted bugs                           [Fail]
CVE-2023-52457:In the Linux kernel, the following vulnerability has been resolved:
serial: 8250: omap: Don't skip resource freeing if pm_runtime_resume_and_get() failed
Returning an error code from .remove() makes the driver core emit the
little helpful error message:
	remove callback returned a non-zero value. This will be ignored.
and then remove the device anyhow. So all resources that were not freed
are leaked in this case. Skipping serial8250_unregister_port() has the
potential to keep enough of the UART around to trigger a use-after-free.
So replace the error return (and with it the little helpful error
message) by a more useful error message and continue to cleanup.
CVE-2023-52610:In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_ct: fix skb leak and crash on ooo frags
act_ct adds skb-&gt;users before defragmentation. If frags arrive in order,
the last frag's reference is reset in:
  inet_frag_reasm_prepare
    skb_morph
which is not straightforward.
However when frags arrive out of order, nobody unref the last frag, and
all frags are leaked. The situation is even worse, as initiating packet
capture can lead to a crash[0] when skb has been cloned and shared at the
same time.
Fix the issue by removing skb_get() before defragmentation. act_ct
returns TC_ACT_CONSUMED when defrag failed or in progress.
[0]:
[  843.804823] ------------[ cut here ]------------
[  843.809659] kernel BUG at net/core/skbuff.c:2091!
[  843.814516] invalid opcode: 0000 [#1] PREEMPT SMP
[  843.819296] CPU: 7 PID: 0 Comm: swapper/7 Kdump: loaded Tainted: G S 6.7.0-rc3 #2
[  843.824107] Hardware name: XFUSION 1288H V6/BC13MBSBD, BIOS 1.29 11/25/2022
[  843.828953] RIP: 0010:pskb_expand_head+0x2ac/0x300
[  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
[  843.843698] RSP: 0018:ffffc9000cce07c0 EFLAGS: 00010202
[  843.848524] RAX: 0000000000000002 RBX: ffff88811a211d00 RCX: 0000000000000820
[  843.853299] RDX: 0000000000000640 RSI: 0000000000000000 RDI: ffff88811a211d00
[  843.857974] RBP: ffff888127d39518 R08: 00000000bee97314 R09: 0000000000000000
[  843.862584] R10: 0000000000000000 R11: ffff8881109f0000 R12: 0000000000000880
[  843.867147] R13: ffff888127d39580 R14: 0000000000000640 R15: ffff888170f7b900
[  843.871680] FS:  0000000000000000(0000) GS:ffff889ffffc0000(0000) knlGS:0000000000000000
[  843.876242] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  843.880778] CR2: 00007fa42affcfb8 CR3: 000000011433a002 CR4: 0000000000770ef0
[  843.885336] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  843.889809] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  843.894229] PKRU: 55555554
[  843.898539] Call Trace:
[  843.902772]  &lt;IRQ&gt;
[  843.906922]  ? __die_body+0x1e/0x60
[  843.911032]  ? die+0x3c/0x60
[  843.915037]  ? do_trap+0xe2/0x110
[  843.918911]  ? pskb_expand_head+0x2ac/0x300
[  843.922687]  ? do_error_trap+0x65/0x80
[  843.926342]  ? pskb_expand_head+0x2ac/0x300
[  843.929905]  ? exc_invalid_op+0x50/0x60
[  843.933398]  ? pskb_expand_head+0x2ac/0x300
[  843.936835]  ? asm_exc_invalid_op+0x1a/0x20
[  843.940226]  ? pskb_expand_head+0x2ac/0x300
[  843.943580]  inet_frag_reasm_prepare+0xd1/0x240
[  843.946904]  ip_defrag+0x5d4/0x870
[  843.950132]  nf_ct_handle_fragments+0xec/0x130 [nf_conntrack]
[  843.953334]  tcf_ct_act+0x252/0xd90 [act_ct]
[  843.956473]  ? tcf_mirred_act+0x516/0x5a0 [act_mirred]
[  843.959657]  tcf_action_exec+0xa1/0x160
[  843.962823]  fl_classify+0x1db/0x1f0 [cls_flower]
[  843.966010]  ? skb_clone+0x53/0xc0
[  843.969173]  tcf_classify+0x24d/0x420
[  843.972333]  tc_run+0x8f/0xf0
[  843.975465]  __netif_receive_skb_core+0x67a/0x1080
[  843.978634]  ? dev_gro_receive+0x249/0x730
[  843.981759]  __netif_receive_skb_list_core+0x12d/0x260
[  843.984869]  netif_receive_skb_list_internal+0x1cb/0x2f0
[  843.987957]  ? mlx5e_handle_rx_cqe_mpwrq_rep+0xfa/0x1a0 [mlx5_core]
[  843.991170]  napi_complete_done+0x72/0x1a0
[  843.994305]  mlx5e_napi_poll+0x28c/0x6d0 [mlx5_core]
[  843.997501]  __napi_poll+0x25/0x1b0
[  844.000627]  net_rx_action+0x256/0x330
[  844.003705]  __do_softirq+0xb3/0x29b
[  844.006718]  irq_exit_rcu+0x9e/0xc0
[  844.009672]  common_interrupt+0x86/0xa0
[  844.012537]  &lt;/IRQ&gt;
[  844.015285]  &lt;TASK&gt;
[  844.017937]  asm_common_interrupt+0x26/0x40
[  844.020591] RIP: 0010:acpi_safe_halt+0x1b/0x20
[  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
---truncated---
CVE-2023-52612:In the Linux kernel, the following vulnerability has been resolved:
crypto: scomp - fix req-&gt;dst buffer overflow
The req-&gt;dst buffer size should be checked before copying from the
scomp_scratch-&gt;dst to avoid req-&gt;dst buffer overflow problem.
CVE-2023-52614:In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Fix buffer overflow in trans_stat_show
Fix buffer overflow in trans_stat_show().
Convert simple snprintf to the more secure scnprintf with size of
PAGE_SIZE.
Add condition checking if we are exceeding PAGE_SIZE and exit early from
loop. Also add at the end a warning that we exceeded PAGE_SIZE and that
stats is disabled.
Return -EFBIG in the case where we don't have enough space to write the
full transition table.
Also document in the ABI that this function can return -EFBIG error.
CVE-2023-52627:In the Linux kernel, the following vulnerability has been resolved:
iio: adc: ad7091r: Allow users to configure device events
AD7091R-5 devices are supported by the ad7091r-5 driver together with
the ad7091r-base driver. Those drivers declared iio events for notifying
user space when ADC readings fall bellow the thresholds of low limit
registers or above the values set in high limit registers.
However, to configure iio events and their thresholds, a set of callback
functions must be implemented and those were not present until now.
The consequence of trying to configure ad7091r-5 events without the
proper callback functions was a null pointer dereference in the kernel
because the pointers to the callback functions were not set.
Implement event configuration callbacks allowing users to read/write
event thresholds and enable/disable event generation.
Since the event spec structs are generic to AD7091R devices, also move
those from the ad7091r-5 driver the base driver so they can be reused
when support for ad7091r-2/-4/-8 be added.
CVE-2023-52646:In the Linux kernel, the following vulnerability has been resolved:
aio: fix mremap after fork null-deref
Commit e4a0d3e720e7 (&quot;aio: Make it possible to remap aio ring&quot;) introduced
a null-deref if mremap is called on an old aio mapping after fork as
mm-&gt;ioctx_table will be set to NULL.
[jmoyer@redhat.com: fix 80 column issue]
CVE-2023-52652:In the Linux kernel, the following vulnerability has been resolved:
NTB: fix possible name leak in ntb_register_device()
If device_register() fails in ntb_register_device(), the device name
allocated by dev_set_name() should be freed. As per the comment in
device_register(), callers should use put_device() to give up the
reference in the error path. So fix this by calling put_device() in the
error path so that the name can be freed in kobject_cleanup().
As a result of this, put_device() in the error path of
ntb_register_device() is removed and the actual error is returned.
[mani: reworded commit message]
CVE-2023-52686:In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_event_init()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
CVE-2023-52753:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Avoid NULL dereference of timing generator
[Why &amp; How]
Check whether assigned timing generator is NULL or not before
accessing its funcs to prevent NULL dereference.
CVE-2023-52802:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-52806:In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: Fix possible null-ptr-deref when assigning a stream
While AudioDSP drivers assign streams exclusively of HOST or LINK type,
nothing blocks a user to attempt to assign a COUPLED stream. As
supplied substream instance may be a stub, what is the case when
code-loading, such scenario ends with null-ptr-deref.
CVE-2023-52814:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix potential null pointer derefernce
The amdgpu_ras_get_context may return NULL if device
not support ras feature, so add check before using.
CVE-2023-52817:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULL
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:
1. Navigate to the directory: /sys/kernel/debug/dri/0
2. Execute command: cat amdgpu_regs_smc
3. Exception Log::
[4005007.702554] BUG: kernel NULL pointer dereference, address: 0000000000000000
[4005007.702562] #PF: supervisor instruction fetch in kernel mode
[4005007.702567] #PF: error_code(0x0010) - not-present page
[4005007.702570] PGD 0 P4D 0
[4005007.702576] Oops: 0010 [#1] SMP NOPTI
[4005007.702581] CPU: 4 PID: 62563 Comm: cat Tainted: G           OE     5.15.0-43-generic #46-Ubunt       u
[4005007.702590] RIP: 0010:0x0
[4005007.702598] Code: Unable to access opcode bytes at RIP 0xffffffffffffffd6.
[4005007.702600] RSP: 0018:ffffa82b46d27da0 EFLAGS: 00010206
[4005007.702605] RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffa82b46d27e68
[4005007.702609] RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff9940656e0000
[4005007.702612] RBP: ffffa82b46d27dd8 R08: 0000000000000000 R09: ffff994060c07980
[4005007.702615] R10: 0000000000020000 R11: 0000000000000000 R12: 00007f5e06753000
[4005007.702618] R13: ffff9940656e0000 R14: ffffa82b46d27e68 R15: 00007f5e06753000
[4005007.702622] FS:  00007f5e0755b740(0000) GS:ffff99479d300000(0000) knlGS:0000000000000000
[4005007.702626] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[4005007.702629] CR2: ffffffffffffffd6 CR3: 00000003253fc000 CR4: 00000000003506e0
[4005007.702633] Call Trace:
[4005007.702636]  &lt;TASK&gt;
[4005007.702640]  amdgpu_debugfs_regs_smc_read+0xb0/0x120 [amdgpu]
[4005007.703002]  full_proxy_read+0x5c/0x80
[4005007.703011]  vfs_read+0x9f/0x1a0
[4005007.703019]  ksys_read+0x67/0xe0
[4005007.703023]  __x64_sys_read+0x19/0x20
[4005007.703028]  do_syscall_64+0x5c/0xc0
[4005007.703034]  ? do_user_addr_fault+0x1e3/0x670
[4005007.703040]  ? exit_to_user_mode_prepare+0x37/0xb0
[4005007.703047]  ? irqentry_exit_to_user_mode+0x9/0x20
[4005007.703052]  ? irqentry_exit+0x19/0x30
[4005007.703057]  ? exc_page_fault+0x89/0x160
[4005007.703062]  ? asm_exc_page_fault+0x8/0x30
[4005007.703068]  entry_SYSCALL_64_after_hwframe+0x44/0xae
[4005007.703075] RIP: 0033:0x7f5e07672992
[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
[4005007.703083] RSP: 002b:00007ffe03097898 EFLAGS: 00000246 ORIG_RAX: 0000000000000000
[4005007.703088] RAX: ffffffffffffffda RBX: 0000000000020000 RCX: 00007f5e07672992
[4005007.703091] RDX: 0000000000020000 RSI: 00007f5e06753000 RDI: 0000000000000003
[4005007.703094] RBP: 00007f5e06753000 R08: 00007f5e06752010 R09: 00007f5e06752010
[4005007.703096] R10: 0000000000000022 R11: 0000000000000246 R12: 0000000000022000
[4005007.703099] R13: 0000000000000003 R14: 0000000000020000 R15: 0000000000020000
[4005007.703105]  &lt;/TASK&gt;
[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
[4005007.703184] CR2: 0000000000000000
[4005007.703188] ---[ en
---truncated---
CVE-2023-52821:In the Linux kernel, the following vulnerability has been resolved:
drm/panel: fix a possible null pointer dereference
In versatile_panel_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2023-52843:In the Linux kernel, the following vulnerability has been resolved:
llc: verify mac len before reading mac header
LLC reads the mac header with eth_hdr without verifying that the skb
has an Ethernet header.
Syzbot was able to enter llc_rcv on a tun device. Tun can insert
packets without mac len and with user configurable skb-&gt;protocol
(passing a tun_pi header when not configuring IFF_NO_PI).
    BUG: KMSAN: uninit-value in llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
    BUG: KMSAN: uninit-value in llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
    llc_station_ac_send_test_r net/llc/llc_station.c:81 [inline]
    llc_station_rcv+0x6fb/0x1290 net/llc/llc_station.c:111
    llc_rcv+0xc5d/0x14a0 net/llc/llc_input.c:218
    __netif_receive_skb_one_core net/core/dev.c:5523 [inline]
    __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5637
    netif_receive_skb_internal net/core/dev.c:5723 [inline]
    netif_receive_skb+0x58/0x660 net/core/dev.c:5782
    tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
    tun_get_user+0x54c5/0x69c0 drivers/net/tun.c:2002
Add a mac_len test before all three eth_hdr(skb) calls under net/llc.
There are further uses in include/net/llc_pdu.h. All these are
protected by a test skb-&gt;protocol == ETH_P_802_2. Which does not
protect against this tun scenario.
But the mac_len test added in this patch in llc_fixup_skb will
indirectly protect those too. That is called from llc_rcv before any
other LLC code.
It is tempting to just add a blanket mac_len check in llc_rcv, but
not sure whether that could break valid LLC paths that do not assume
an Ethernet header. 802.2 LLC may be used on top of non-802.3
protocols in principle. The below referenced commit shows that used
to, on top of Token Ring.
At least one of the three eth_hdr uses goes back to before the start
of git history. But the one that syzbot exercises is introduced in
this commit. That commit is old enough (2008), that effectively all
stable kernels should receive this.
CVE-2023-52845:In the Linux kernel, the following vulnerability has been resolved:
tipc: Change nla_policy for bearer-related names to NLA_NUL_STRING
syzbot reported the following uninit-value access issue [1]:
=====================================================
BUG: KMSAN: uninit-value in strlen lib/string.c:418 [inline]
BUG: KMSAN: uninit-value in strstr+0xb8/0x2f0 lib/string.c:756
 strlen lib/string.c:418 [inline]
 strstr+0xb8/0x2f0 lib/string.c:756
 tipc_nl_node_reset_link_stats+0x3ea/0xb50 net/tipc/node.c:2595
 genl_family_rcv_msg_doit net/netlink/genetlink.c:971 [inline]
 genl_family_rcv_msg net/netlink/genetlink.c:1051 [inline]
 genl_rcv_msg+0x11ec/0x1290 net/netlink/genetlink.c:1066
 netlink_rcv_skb+0x371/0x650 net/netlink/af_netlink.c:2545
 genl_rcv+0x40/0x60 net/netlink/genetlink.c:1075
 netlink_unicast_kernel net/netlink/af_netlink.c:1342 [inline]
 netlink_unicast+0xf47/0x1250 net/netlink/af_netlink.c:1368
 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
 sock_sendmsg_nosec net/socket.c:730 [inline]
 sock_sendmsg net/socket.c:753 [inline]
 ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
 __sys_sendmsg net/socket.c:2624 [inline]
 __do_sys_sendmsg net/socket.c:2633 [inline]
 __se_sys_sendmsg net/socket.c:2631 [inline]
 __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
Uninit was created at:
 slab_post_alloc_hook+0x12f/0xb70 mm/slab.h:767
 slab_alloc_node mm/slub.c:3478 [inline]
 kmem_cache_alloc_node+0x577/0xa80 mm/slub.c:3523
 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:559
 __alloc_skb+0x318/0x740 net/core/skbuff.c:650
 alloc_skb include/linux/skbuff.h:1286 [inline]
 netlink_alloc_large_skb net/netlink/af_netlink.c:1214 [inline]
 netlink_sendmsg+0xb34/0x13d0 net/netlink/af_netlink.c:1885
 sock_sendmsg_nosec net/socket.c:730 [inline]
 sock_sendmsg net/socket.c:753 [inline]
 ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2541
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2595
 __sys_sendmsg net/socket.c:2624 [inline]
 __do_sys_sendmsg net/socket.c:2633 [inline]
 __se_sys_sendmsg net/socket.c:2631 [inline]
 __x64_sys_sendmsg+0x307/0x490 net/socket.c:2631
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x41/0xc0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
TIPC bearer-related names including link names must be null-terminated
strings. If a link name which is not null-terminated is passed through
netlink, strstr() and similar functions can cause buffer overrun. This
causes the above issue.
This patch changes the nla_policy for bearer-related names from NLA_STRING
to NLA_NUL_STRING. This resolves the issue by ensuring that only
null-terminated strings are accepted as bearer-related names.
syzbot reported similar uninit-value issue related to bearer names [2]. The
root cause of this issue is that a non-null-terminated bearer name was
passed. This patch also resolved this issue.
CVE-2023-52846:In the Linux kernel, the following vulnerability has been resolved:
hsr: Prevent use after free in prp_create_tagged_frame()
The prp_fill_rct() function can fail.  In that situation, it frees the
skb and returns NULL.  Meanwhile on the success path, it returns the
original skb.  So it's straight forward to fix bug by using the returned
value.
CVE-2023-52853:In the Linux kernel, the following vulnerability has been resolved:
hid: cp2112: Fix duplicate workqueue initialization
Previously the cp2112 driver called INIT_DELAYED_WORK within
cp2112_gpio_irq_startup, resulting in duplicate initilizations of the
workqueue on subsequent IRQ startups following an initial request. This
resulted in a warning in set_work_data in workqueue.c, as well as a rare
NULL dereference within process_one_work in workqueue.c.
Initialize the workqueue within _probe instead.
CVE-2023-52855:In the Linux kernel, the following vulnerability has been resolved:
usb: dwc2: fix possible NULL pointer dereference caused by driver concurrency
In _dwc2_hcd_urb_enqueue(), &quot;urb-&gt;hcpriv = NULL&quot; is executed without
holding the lock &quot;hsotg-&gt;lock&quot;. In _dwc2_hcd_urb_dequeue():
    spin_lock_irqsave(&amp;hsotg-&gt;lock, flags);
    ...
	if (!urb-&gt;hcpriv) {
		dev_dbg(hsotg-&gt;dev, &quot;## urb-&gt;hcpriv is NULL ##\n&quot;);
		goto out;
	}
    rc = dwc2_hcd_urb_dequeue(hsotg, urb-&gt;hcpriv); // Use urb-&gt;hcpriv
    ...
out:
    spin_unlock_irqrestore(&amp;hsotg-&gt;lock, flags);
When _dwc2_hcd_urb_enqueue() and _dwc2_hcd_urb_dequeue() are
concurrently executed, the NULL check of &quot;urb-&gt;hcpriv&quot; can be executed
before &quot;urb-&gt;hcpriv = NULL&quot;. After urb-&gt;hcpriv is NULL, it can be used
in the function call to dwc2_hcd_urb_dequeue(), which can cause a NULL
pointer dereference.
This possible bug is found by an experimental static analysis tool
developed by myself. This tool analyzes the locking APIs to extract
function pairs that can be concurrently executed, and then analyzes the
instructions in the paired functions to identify possible concurrency
bugs including data races and atomicity violations. The above possible
bug is reported, when my tool analyzes the source code of Linux 6.5.
To fix this possible bug, &quot;urb-&gt;hcpriv = NULL&quot; should be executed with
holding the lock &quot;hsotg-&gt;lock&quot;. After using this patch, my tool never
reports the possible bug, with the kernelconfiguration allyesconfig for
x86_64. Because I have no associated hardware, I cannot test the patch
in runtime testing, and just verify it according to the code logic.
CVE-2023-52858:In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
CVE-2023-52864:In the Linux kernel, the following vulnerability has been resolved:
platform/x86: wmi: Fix opening of char device
Since commit fa1f68db6ca7 (&quot;drivers: misc: pass miscdevice pointer via
file private data&quot;), the miscdevice stores a pointer to itself inside
filp-&gt;private_data, which means that private_data will not be NULL when
wmi_char_open() is called. This might cause memory corruption should
wmi_char_open() be unable to find its driver, something which can
happen when the associated WMI device is deleted in wmi_free_devices().
Fix the problem by using the miscdevice pointer to retrieve the WMI
device data associated with a char device using container_of(). This
also avoids wmi_char_open() picking a wrong WMI device bound to a
driver with the same name as the original driver.
CVE-2023-52865:In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
CVE-2023-52868:In the Linux kernel, the following vulnerability has been resolved:
thermal: core: prevent potential string overflow
The dev-&gt;id value comes from ida_alloc() so it's a number between zero
and INT_MAX.  If it's too high then these sprintf()s will overflow.
CVE-2023-52871:In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: llcc: Handle a second device without data corruption
Usually there is only one llcc device. But if there were a second, even
a failed probe call would modify the global drv_data pointer. So check
if drv_data is valid before overwriting it.
CVE-2023-52873:In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
CVE-2023-52875:In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
CVE-2023-52876:In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
CVE-2024-24855:A race condition was found in the Linux kernel'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.
CVE-2024-26594:In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate mech token in session setup
If client send invalid mech token in session setup request, ksmbd
validate and make the error if it is invalid.
CVE-2024-26602:In the Linux kernel, the following vulnerability has been resolved:
sched/membarrier: reduce the ability to hammer on sys_membarrier
On some systems, sys_membarrier can be very expensive, causing overall
slowdowns for everything.  So put a lock on the path in order to
serialize the accesses to prevent the ability for this to be called at
too high of a frequency and saturate the machine.
CVE-2024-26663:In the Linux kernel, the following vulnerability has been resolved:
tipc: Check the bearer type before calling tipc_udp_nl_bearer_add()
syzbot reported the following general protection fault [1]:
general protection fault, probably for non-canonical address 0xdffffc0000000010: 0000 [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000080-0x0000000000000087]
...
RIP: 0010:tipc_udp_is_known_peer+0x9c/0x250 net/tipc/udp_media.c:291
...
Call Trace:
 &lt;TASK&gt;
 tipc_udp_nl_bearer_add+0x212/0x2f0 net/tipc/udp_media.c:646
 tipc_nl_bearer_add+0x21e/0x360 net/tipc/bearer.c:1089
 genl_family_rcv_msg_doit+0x1fc/0x2e0 net/netlink/genetlink.c:972
 genl_family_rcv_msg net/netlink/genetlink.c:1052 [inline]
 genl_rcv_msg+0x561/0x800 net/netlink/genetlink.c:1067
 netlink_rcv_skb+0x16b/0x440 net/netlink/af_netlink.c:2544
 genl_rcv+0x28/0x40 net/netlink/genetlink.c:1076
 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
 netlink_unicast+0x53b/0x810 net/netlink/af_netlink.c:1367
 netlink_sendmsg+0x8b7/0xd70 net/netlink/af_netlink.c:1909
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0xd5/0x180 net/socket.c:745
 ____sys_sendmsg+0x6ac/0x940 net/socket.c:2584
 ___sys_sendmsg+0x135/0x1d0 net/socket.c:2638
 __sys_sendmsg+0x117/0x1e0 net/socket.c:2667
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
The cause of this issue is that when tipc_nl_bearer_add() is called with
the TIPC_NLA_BEARER_UDP_OPTS attribute, tipc_udp_nl_bearer_add() is called
even if the bearer is not UDP.
tipc_udp_is_known_peer() called by tipc_udp_nl_bearer_add() assumes that
the media_ptr field of the tipc_bearer has an udp_bearer type object, so
the function goes crazy for non-UDP bearers.
This patch fixes the issue by checking the bearer type before calling
tipc_udp_nl_bearer_add() in tipc_nl_bearer_add().
CVE-2024-26673:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_ct: sanitize layer 3 and 4 protocol number in custom expectations
- Disallow families other than NFPROTO_{IPV4,IPV6,INET}.
- Disallow layer 4 protocol with no ports, since destination port is a
  mandatory attribute for this object.
CVE-2024-26813:In the Linux kernel, the following vulnerability has been resolved:
vfio/platform: Create persistent IRQ handlers
The vfio-platform SET_IRQS ioctl currently allows loopback triggering of
an interrupt before a signaling eventfd has been configured by the user,
which thereby allows a NULL pointer dereference.
Rather than register the IRQ relative to a valid trigger, register all
IRQs in a disabled state in the device open path.  This allows mask
operations on the IRQ to nest within the overall enable state governed
by a valid eventfd signal.  This decouples @masked, protected by the
@locked spinlock from @trigger, protected via the @igate mutex.
In doing so, it's guaranteed that changes to @trigger cannot race the
IRQ handlers because the IRQ handler is synchronously disabled before
modifying the trigger, and loopback triggering of the IRQ via ioctl is
safe due to serialization with trigger changes via igate.
For compatibility, request_irq() failures are maintained to be local to
the SET_IRQS ioctl rather than a fatal error in the open device path.
This allows, for example, a userspace driver with polling mode support
to continue to work regardless of moving the request_irq() call site.
This necessarily blocks all SET_IRQS access to the failed index.
CVE-2024-26825:In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: free rx_data_reassembly skb on NCI device cleanup
rx_data_reassembly skb is stored during NCI data exchange for processing
fragmented packets. It is dropped only when the last fragment is processed
or when an NTF packet with NCI_OP_RF_DEACTIVATE_NTF opcode is received.
However, the NCI device may be deallocated before that which leads to skb
leak.
As by design the rx_data_reassembly skb is bound to the NCI device and
nothing prevents the device to be freed before the skb is processed in
some way and cleaned, free it on the NCI device cleanup.
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2024-26829:In the Linux kernel, the following vulnerability has been resolved:
media: ir_toy: fix a memleak in irtoy_tx
When irtoy_command fails, buf should be freed since it is allocated by
irtoy_tx, or there is a memleak.
CVE-2024-26830:In the Linux kernel, the following vulnerability has been resolved:
i40e: Do not allow untrusted VF to remove administratively set MAC
Currently when PF administratively sets VF's MAC address and the VF
is put down (VF tries to delete all MACs) then the MAC is removed
from MAC filters and primary VF MAC is zeroed.
Do not allow untrusted VF to remove primary MAC when it was set
administratively by PF.
Reproducer:
1) Create VF
2) Set VF interface up
3) Administratively set the VF's MAC
4) Put VF interface down
[root@host ~]# echo 1 &gt; /sys/class/net/enp2s0f0/device/sriov_numvfs
[root@host ~]# ip link set enp2s0f0v0 up
[root@host ~]# ip link set enp2s0f0 vf 0 mac fe:6c:b5:da:c7:7d
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
    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
[root@host ~]# ip link set enp2s0f0v0 down
[root@host ~]# ip link show enp2s0f0
23: enp2s0f0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc mq state UP mode DEFAULT group default qlen 1000
    link/ether 3c:ec:ef:b7:dd:04 brd ff:ff:ff:ff:ff:ff
    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
CVE-2024-26857:In the Linux kernel, the following vulnerability has been resolved:
geneve: make sure to pull inner header in geneve_rx()
syzbot triggered a bug in geneve_rx() [1]
Issue is similar to the one I fixed in commit 8d975c15c0cd
(&quot;ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()&quot;)
We have to save skb-&gt;network_header in a temporary variable
in order to be able to recompute the network_header pointer
after a pskb_inet_may_pull() call.
pskb_inet_may_pull() makes sure the needed headers are in skb-&gt;head.
[1]
BUG: KMSAN: uninit-value in IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
 BUG: KMSAN: uninit-value in geneve_rx drivers/net/geneve.c:279 [inline]
 BUG: KMSAN: uninit-value in geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
  IP_ECN_decapsulate include/net/inet_ecn.h:302 [inline]
  geneve_rx drivers/net/geneve.c:279 [inline]
  geneve_udp_encap_recv+0x36f9/0x3c10 drivers/net/geneve.c:391
  udp_queue_rcv_one_skb+0x1d39/0x1f20 net/ipv4/udp.c:2108
  udp_queue_rcv_skb+0x6ae/0x6e0 net/ipv4/udp.c:2186
  udp_unicast_rcv_skb+0x184/0x4b0 net/ipv4/udp.c:2346
  __udp4_lib_rcv+0x1c6b/0x3010 net/ipv4/udp.c:2422
  udp_rcv+0x7d/0xa0 net/ipv4/udp.c:2604
  ip_protocol_deliver_rcu+0x264/0x1300 net/ipv4/ip_input.c:205
  ip_local_deliver_finish+0x2b8/0x440 net/ipv4/ip_input.c:233
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip_local_deliver+0x21f/0x490 net/ipv4/ip_input.c:254
  dst_input include/net/dst.h:461 [inline]
  ip_rcv_finish net/ipv4/ip_input.c:449 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip_rcv+0x46f/0x760 net/ipv4/ip_input.c:569
  __netif_receive_skb_one_core net/core/dev.c:5534 [inline]
  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5648
  process_backlog+0x480/0x8b0 net/core/dev.c:5976
  __napi_poll+0xe3/0x980 net/core/dev.c:6576
  napi_poll net/core/dev.c:6645 [inline]
  net_rx_action+0x8b8/0x1870 net/core/dev.c:6778
  __do_softirq+0x1b7/0x7c5 kernel/softirq.c:553
  do_softirq+0x9a/0xf0 kernel/softirq.c:454
  __local_bh_enable_ip+0x9b/0xa0 kernel/softirq.c:381
  local_bh_enable include/linux/bottom_half.h:33 [inline]
  rcu_read_unlock_bh include/linux/rcupdate.h:820 [inline]
  __dev_queue_xmit+0x2768/0x51c0 net/core/dev.c:4378
  dev_queue_xmit include/linux/netdevice.h:3171 [inline]
  packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3081 [inline]
  packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  __sys_sendto+0x735/0xa10 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3819 [inline]
  slab_alloc_node mm/slub.c:3860 [inline]
  kmem_cache_alloc_node+0x5cb/0xbc0 mm/slub.c:3903
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
  __alloc_skb+0x352/0x790 net/core/skbuff.c:651
  alloc_skb include/linux/skbuff.h:1296 [inline]
  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6394
  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2783
  packet_alloc_skb net/packet/af_packet.c:2930 [inline]
  packet_snd net/packet/af_packet.c:3024 [inline]
  packet_sendmsg+0x70c2/0x9f10 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  __sys_sendto+0x735/0xa10 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CVE-2024-26862:In the Linux kernel, the following vulnerability has been resolved:
packet: annotate data-races around ignore_outgoing
ignore_outgoing is read locklessly from dev_queue_xmit_nit()
and packet_getsockopt()
Add appropriate READ_ONCE()/WRITE_ONCE() annotations.
syzbot reported:
BUG: KCSAN: data-race in dev_queue_xmit_nit / packet_setsockopt
write to 0xffff888107804542 of 1 bytes by task 22618 on cpu 0:
 packet_setsockopt+0xd83/0xfd0 net/packet/af_packet.c:4003
 do_sock_setsockopt net/socket.c:2311 [inline]
 __sys_setsockopt+0x1d8/0x250 net/socket.c:2334
 __do_sys_setsockopt net/socket.c:2343 [inline]
 __se_sys_setsockopt net/socket.c:2340 [inline]
 __x64_sys_setsockopt+0x66/0x80 net/socket.c:2340
 do_syscall_64+0xd3/0x1d0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff888107804542 of 1 bytes by task 27 on cpu 1:
 dev_queue_xmit_nit+0x82/0x620 net/core/dev.c:2248
 xmit_one net/core/dev.c:3527 [inline]
 dev_hard_start_xmit+0xcc/0x3f0 net/core/dev.c:3547
 __dev_queue_xmit+0xf24/0x1dd0 net/core/dev.c:4335
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 batadv_send_skb_packet+0x264/0x300 net/batman-adv/send.c:108
 batadv_send_broadcast_skb+0x24/0x30 net/batman-adv/send.c:127
 batadv_iv_ogm_send_to_if net/batman-adv/bat_iv_ogm.c:392 [inline]
 batadv_iv_ogm_emit net/batman-adv/bat_iv_ogm.c:420 [inline]
 batadv_iv_send_outstanding_bat_ogm_packet+0x3f0/0x4b0 net/batman-adv/bat_iv_ogm.c:1700
 process_one_work kernel/workqueue.c:3254 [inline]
 process_scheduled_works+0x465/0x990 kernel/workqueue.c:3335
 worker_thread+0x526/0x730 kernel/workqueue.c:3416
 kthread+0x1d1/0x210 kernel/kthread.c:388
 ret_from_fork+0x4b/0x60 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
value changed: 0x00 -&gt; 0x01
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 27 Comm: kworker/u8:1 Tainted: G        W          6.8.0-syzkaller-08073-g480e035fc4c7 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Workqueue: bat_events batadv_iv_send_outstanding_bat_ogm_packet
CVE-2024-26863:In the Linux kernel, the following vulnerability has been resolved:
hsr: Fix uninit-value access in hsr_get_node()
KMSAN reported the following uninit-value access issue [1]:
=====================================================
BUG: KMSAN: uninit-value in hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
 hsr_get_node+0xa2e/0xa40 net/hsr/hsr_framereg.c:246
 fill_frame_info net/hsr/hsr_forward.c:577 [inline]
 hsr_forward_skb+0xe12/0x30e0 net/hsr/hsr_forward.c:615
 hsr_dev_xmit+0x1a1/0x270 net/hsr/hsr_device.c:223
 __netdev_start_xmit include/linux/netdevice.h:4940 [inline]
 netdev_start_xmit include/linux/netdevice.h:4954 [inline]
 xmit_one net/core/dev.c:3548 [inline]
 dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
 __dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
 dev_queue_xmit include/linux/netdevice.h:3134 [inline]
 packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3087 [inline]
 packet_sendmsg+0x8b1d/0x9f30 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x735/0xa10 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
 slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
 slab_alloc_node mm/slub.c:3478 [inline]
 kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
 kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
 __alloc_skb+0x318/0x740 net/core/skbuff.c:651
 alloc_skb include/linux/skbuff.h:1286 [inline]
 alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
 sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
 packet_alloc_skb net/packet/af_packet.c:2936 [inline]
 packet_snd net/packet/af_packet.c:3030 [inline]
 packet_sendmsg+0x70e8/0x9f30 net/packet/af_packet.c:3119
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x735/0xa10 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 1 PID: 5033 Comm: syz-executor334 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
=====================================================
If the packet type ID field in the Ethernet header is either ETH_P_PRP or
ETH_P_HSR, but it is not followed by an HSR tag, hsr_get_skb_sequence_nr()
reads an invalid value as a sequence number. This causes the above issue.
This patch fixes the issue by returning NULL if the Ethernet header is not
followed by an HSR tag.
CVE-2024-26865:In the Linux kernel, the following vulnerability has been resolved:
rds: tcp: Fix use-after-free of net in reqsk_timer_handler().
syzkaller reported a warning of netns tracker [0] followed by KASAN
splat [1] and another ref tracker warning [1].
syzkaller could not find a repro, but in the log, the only suspicious
sequence was as follows:
  18:26:22 executing program 1:
  r0 = socket$inet6_mptcp(0xa, 0x1, 0x106)
  ...
  connect$inet6(r0, &amp;(0x7f0000000080)={0xa, 0x4001, 0x0, @loopback}, 0x1c) (async)
The notable thing here is 0x4001 in connect(), which is RDS_TCP_PORT.
So, the scenario would be:
  1. unshare(CLONE_NEWNET) creates a per netns tcp listener in
      rds_tcp_listen_init().
  2. syz-executor connect()s to it and creates a reqsk.
  3. syz-executor exit()s immediately.
  4. netns is dismantled.  [0]
  5. reqsk timer is fired, and UAF happens while freeing reqsk.  [1]
  6. listener is freed after RCU grace period.  [2]
Basically, reqsk assumes that the listener guarantees netns safety
until all reqsk timers are expired by holding the listener's refcount.
However, this was not the case for kernel sockets.
Commit 740ea3c4a0b2 (&quot;tcp: Clean up kernel listener's reqsk in
inet_twsk_purge()&quot;) fixed this issue only for per-netns ehash.
Let's apply the same fix for the global ehash.
[0]:
ref_tracker: net notrefcnt@0000000065449cc3 has 1/1 users at
     sk_alloc (./include/net/net_namespace.h:337 net/core/sock.c:2146)
     inet6_create (net/ipv6/af_inet6.c:192 net/ipv6/af_inet6.c:119)
     __sock_create (net/socket.c:1572)
     rds_tcp_listen_init (net/rds/tcp_listen.c:279)
     rds_tcp_init_net (net/rds/tcp.c:577)
     ops_init (net/core/net_namespace.c:137)
     setup_net (net/core/net_namespace.c:340)
     copy_net_ns (net/core/net_namespace.c:497)
     create_new_namespaces (kernel/nsproxy.c:110)
     unshare_nsproxy_namespaces (kernel/nsproxy.c:228 (discriminator 4))
     ksys_unshare (kernel/fork.c:3429)
     __x64_sys_unshare (kernel/fork.c:3496)
     do_syscall_64 (arch/x86/entry/common.c:52 arch/x86/entry/common.c:83)
     entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)
...
WARNING: CPU: 0 PID: 27 at lib/ref_tracker.c:179 ref_tracker_dir_exit (lib/ref_tracker.c:179)
[1]:
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)
Read of size 8 at addr ffff88801b370400 by task swapper/0/0
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl (lib/dump_stack.c:107 (discriminator 1))
 print_report (mm/kasan/report.c:378 mm/kasan/report.c:488)
 kasan_report (mm/kasan/report.c:603)
 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)
 reqsk_timer_handler (net/ipv4/inet_connection_sock.c:979 net/ipv4/inet_connection_sock.c:1092)
 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)
 __run_timers.part.0 (kernel/time/timer.c:1752 kernel/time/timer.c:2038)
 run_timer_softirq (kernel/time/timer.c:2053)
 __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)
 irq_exit_rcu (kernel/softirq.c:427 kernel/softirq.c:632 kernel/softirq.c:644)
 sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1076 (discriminator 14))
 &lt;/IRQ&gt;
Allocated by task 258 on cpu 0 at 83.612050s:
 kasan_save_stack (mm/kasan/common.c:48)
 kasan_save_track (mm/kasan/common.c:68)
 __kasan_slab_alloc (mm/kasan/common.c:343)
 kmem_cache_alloc (mm/slub.c:3813 mm/slub.c:3860 mm/slub.c:3867)
 copy_net_ns (./include/linux/slab.h:701 net/core/net_namespace.c:421 net/core/net_namespace.c:480)
 create_new_namespaces (kernel/nsproxy.c:110)
 unshare_nsproxy_name
---truncated---
CVE-2024-26869:In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to truncate meta inode pages forcely
Below race case can cause data corruption:
Thread A				GC thread
					- gc_data_segment
					 - ra_data_block
					  - locked meta_inode page
- f2fs_inplace_write_data
 - invalidate_mapping_pages
 : fail to invalidate meta_inode page
   due to lock failure or dirty|writeback
   status
 - f2fs_submit_page_bio
 : write last dirty data to old blkaddr
					 - move_data_block
					  - load old data from meta_inode page
					  - f2fs_submit_page_write
					  : write old data to new blkaddr
Because invalidate_mapping_pages() will skip invalidating page which
has unclear status including locked, dirty, writeback and so on, so
we need to use truncate_inode_pages_range() instead of
invalidate_mapping_pages() to make sure meta_inode page will be dropped.
CVE-2024-26872:In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Do not register event handler until srpt device is fully setup
Upon rare occasions, KASAN reports a use-after-free Write
in srpt_refresh_port().
This seems to be because an event handler is registered before the
srpt device is fully setup and a race condition upon error may leave a
partially setup event handler in place.
Instead, only register the event handler after srpt device initialization
is complete.
CVE-2024-26876:In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: adv7511: fix crash on irq during probe
Moved IRQ registration down to end of adv7511_probe().
If an IRQ already is pending during adv7511_probe
(before adv7511_cec_init) then cec_received_msg_ts
could crash using uninitialized data:
    Unable to handle kernel read from unreadable memory at virtual address 00000000000003d5
    Internal error: Oops: 96000004 [#1] PREEMPT_RT SMP
    Call trace:
     cec_received_msg_ts+0x48/0x990 [cec]
     adv7511_cec_irq_process+0x1cc/0x308 [adv7511]
     adv7511_irq_process+0xd8/0x120 [adv7511]
     adv7511_irq_handler+0x1c/0x30 [adv7511]
     irq_thread_fn+0x30/0xa0
     irq_thread+0x14c/0x238
     kthread+0x190/0x1a8
CVE-2024-26877:In the Linux kernel, the following vulnerability has been resolved:
crypto: xilinx - call finalize with bh disabled
When calling crypto_finalize_request, BH should be disabled to avoid
triggering the following calltrace:
    ------------[ cut here ]------------
    WARNING: CPU: 2 PID: 74 at crypto/crypto_engine.c:58 crypto_finalize_request+0xa0/0x118
    Modules linked in: cryptodev(O)
    CPU: 2 PID: 74 Comm: firmware:zynqmp Tainted: G           O       6.8.0-rc1-yocto-standard #323
    Hardware name: ZynqMP ZCU102 Rev1.0 (DT)
    pstate: 40000005 (nZcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
    pc : crypto_finalize_request+0xa0/0x118
    lr : crypto_finalize_request+0x104/0x118
    sp : ffffffc085353ce0
    x29: ffffffc085353ce0 x28: 0000000000000000 x27: ffffff8808ea8688
    x26: ffffffc081715038 x25: 0000000000000000 x24: ffffff880100db00
    x23: ffffff880100da80 x22: 0000000000000000 x21: 0000000000000000
    x20: ffffff8805b14000 x19: ffffff880100da80 x18: 0000000000010450
    x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
    x14: 0000000000000003 x13: 0000000000000000 x12: ffffff880100dad0
    x11: 0000000000000000 x10: ffffffc0832dcd08 x9 : ffffffc0812416d8
    x8 : 00000000000001f4 x7 : ffffffc0830d2830 x6 : 0000000000000001
    x5 : ffffffc082091000 x4 : ffffffc082091658 x3 : 0000000000000000
    x2 : ffffffc7f9653000 x1 : 0000000000000000 x0 : ffffff8802d20000
    Call trace:
     crypto_finalize_request+0xa0/0x118
     crypto_finalize_aead_request+0x18/0x30
     zynqmp_handle_aes_req+0xcc/0x388
     crypto_pump_work+0x168/0x2d8
     kthread_worker_fn+0xfc/0x3a0
     kthread+0x118/0x138
     ret_from_fork+0x10/0x20
    irq event stamp: 40
    hardirqs last  enabled at (39): [&lt;ffffffc0812416f8&gt;] _raw_spin_unlock_irqrestore+0x70/0xb0
    hardirqs last disabled at (40): [&lt;ffffffc08122d208&gt;] el1_dbg+0x28/0x90
    softirqs last  enabled at (36): [&lt;ffffffc080017dec&gt;] kernel_neon_begin+0x8c/0xf0
    softirqs last disabled at (34): [&lt;ffffffc080017dc0&gt;] kernel_neon_begin+0x60/0xf0
    ---[ end trace 0000000000000000 ]---
CVE-2024-26889:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix possible buffer overflow
struct hci_dev_info has a fixed size name[8] field so in the event that
hdev-&gt;name is bigger than that strcpy would attempt to write past its
size, so this fixes this problem by switching to use strscpy.
CVE-2024-26895:In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: prevent use-after-free on vif when cleaning up all interfaces
wilc_netdev_cleanup currently triggers a KASAN warning, which can be
observed on interface registration error path, or simply by
removing the module/unbinding device from driver:
echo spi0.1 &gt; /sys/bus/spi/drivers/wilc1000_spi/unbind
==================================================================
BUG: KASAN: slab-use-after-free in wilc_netdev_cleanup+0x508/0x5cc
Read of size 4 at addr c54d1ce8 by task sh/86
CPU: 0 PID: 86 Comm: sh Not tainted 6.8.0-rc1+ #117
Hardware name: Atmel SAMA5
 unwind_backtrace from show_stack+0x18/0x1c
 show_stack from dump_stack_lvl+0x34/0x58
 dump_stack_lvl from print_report+0x154/0x500
 print_report from kasan_report+0xac/0xd8
 kasan_report from wilc_netdev_cleanup+0x508/0x5cc
 wilc_netdev_cleanup from wilc_bus_remove+0xc8/0xec
 wilc_bus_remove from spi_remove+0x8c/0xac
 spi_remove from device_release_driver_internal+0x434/0x5f8
 device_release_driver_internal from unbind_store+0xbc/0x108
 unbind_store from kernfs_fop_write_iter+0x398/0x584
 kernfs_fop_write_iter from vfs_write+0x728/0xf88
 vfs_write from ksys_write+0x110/0x1e4
 ksys_write from ret_fast_syscall+0x0/0x1c
[...]
Allocated by task 1:
 kasan_save_track+0x30/0x5c
 __kasan_kmalloc+0x8c/0x94
 __kmalloc_node+0x1cc/0x3e4
 kvmalloc_node+0x48/0x180
 alloc_netdev_mqs+0x68/0x11dc
 alloc_etherdev_mqs+0x28/0x34
 wilc_netdev_ifc_init+0x34/0x8ec
 wilc_cfg80211_init+0x690/0x910
 wilc_bus_probe+0xe0/0x4a0
 spi_probe+0x158/0x1b0
 really_probe+0x270/0xdf4
 __driver_probe_device+0x1dc/0x580
 driver_probe_device+0x60/0x140
 __driver_attach+0x228/0x5d4
 bus_for_each_dev+0x13c/0x1a8
 bus_add_driver+0x2a0/0x608
 driver_register+0x24c/0x578
 do_one_initcall+0x180/0x310
 kernel_init_freeable+0x424/0x484
 kernel_init+0x20/0x148
 ret_from_fork+0x14/0x28
Freed by task 86:
 kasan_save_track+0x30/0x5c
 kasan_save_free_info+0x38/0x58
 __kasan_slab_free+0xe4/0x140
 kfree+0xb0/0x238
 device_release+0xc0/0x2a8
 kobject_put+0x1d4/0x46c
 netdev_run_todo+0x8fc/0x11d0
 wilc_netdev_cleanup+0x1e4/0x5cc
 wilc_bus_remove+0xc8/0xec
 spi_remove+0x8c/0xac
 device_release_driver_internal+0x434/0x5f8
 unbind_store+0xbc/0x108
 kernfs_fop_write_iter+0x398/0x584
 vfs_write+0x728/0xf88
 ksys_write+0x110/0x1e4
 ret_fast_syscall+0x0/0x1c
 [...]
David Mosberger-Tan initial investigation [1] showed that this
use-after-free is due to netdevice unregistration during vif list
traversal. When unregistering a net device, since the needs_free_netdev has
been set to true during registration, the netdevice object is also freed,
and as a consequence, the corresponding vif object too, since it is
attached to it as private netdevice data. The next occurrence of the loop
then tries to access freed vif pointer to the list to move forward in the
list.
Fix this use-after-free thanks to two mechanisms:
- navigate in the list with list_for_each_entry_safe, which allows to
  safely modify the list as we go through each element. For each element,
  remove it from the list with list_del_rcu
- make sure to wait for RCU grace period end after each vif removal to make
  sure it is safe to free the corresponding vif too (through
  unregister_netdev)
Since we are in a RCU &quot;modifier&quot; path (not a &quot;reader&quot; path), and because
such path is expected not to be concurrent to any other modifier (we are
using the vif_mutex lock), we do not need to use RCU list API, that's why
we can benefit from list_for_each_entry_safe.
[1] https://lore.kernel.org/linux-wireless/ab077dbe58b1ea5de0a3b2ca21f275a07af967d2.camel@egauge.net/
CVE-2024-26896:In the Linux kernel, the following vulnerability has been resolved:
wifi: wfx: fix memory leak when starting AP
Kmemleak reported this error:
    unreferenced object 0xd73d1180 (size 184):
      comm &quot;wpa_supplicant&quot;, pid 1559, jiffies 13006305 (age 964.245s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        00 00 00 00 00 00 00 00 1e 00 01 00 00 00 00 00  ................
      backtrace:
        [&lt;5ca11420&gt;] kmem_cache_alloc+0x20c/0x5ac
        [&lt;127bdd74&gt;] __alloc_skb+0x144/0x170
        [&lt;fb8a5e38&gt;] __netdev_alloc_skb+0x50/0x180
        [&lt;0f9fa1d5&gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
        [&lt;7accd02d&gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
        [&lt;41e25cc3&gt;] wfx_start_ap+0xc8/0x234 [wfx]
        [&lt;93a70356&gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]
        [&lt;a4a661cd&gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
        [&lt;47bd8b68&gt;] genl_rcv_msg+0x198/0x378
        [&lt;453ef796&gt;] netlink_rcv_skb+0xd0/0x130
        [&lt;6b7c977a&gt;] genl_rcv+0x34/0x44
        [&lt;66b2d04d&gt;] netlink_unicast+0x1b4/0x258
        [&lt;f965b9b6&gt;] netlink_sendmsg+0x1e8/0x428
        [&lt;aadb8231&gt;] ____sys_sendmsg+0x1e0/0x274
        [&lt;d2b5212d&gt;] ___sys_sendmsg+0x80/0xb4
        [&lt;69954f45&gt;] __sys_sendmsg+0x64/0xa8
    unreferenced object 0xce087000 (size 1024):
      comm &quot;wpa_supplicant&quot;, pid 1559, jiffies 13006305 (age 964.246s)
      hex dump (first 32 bytes):
        00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
        10 00 07 40 00 00 00 00 00 00 00 00 00 00 00 00  ...@............
      backtrace:
        [&lt;9a993714&gt;] __kmalloc_track_caller+0x230/0x600
        [&lt;f83ea192&gt;] kmalloc_reserve.constprop.0+0x30/0x74
        [&lt;a2c61343&gt;] __alloc_skb+0xa0/0x170
        [&lt;fb8a5e38&gt;] __netdev_alloc_skb+0x50/0x180
        [&lt;0f9fa1d5&gt;] __ieee80211_beacon_get+0x290/0x4d4 [mac80211]
        [&lt;7accd02d&gt;] ieee80211_beacon_get_tim+0x54/0x18c [mac80211]
        [&lt;41e25cc3&gt;] wfx_start_ap+0xc8/0x234 [wfx]
        [&lt;93a70356&gt;] ieee80211_start_ap+0x404/0x6b4 [mac80211]
        [&lt;a4a661cd&gt;] nl80211_start_ap+0x76c/0x9e0 [cfg80211]
        [&lt;47bd8b68&gt;] genl_rcv_msg+0x198/0x378
        [&lt;453ef796&gt;] netlink_rcv_skb+0xd0/0x130
        [&lt;6b7c977a&gt;] genl_rcv+0x34/0x44
        [&lt;66b2d04d&gt;] netlink_unicast+0x1b4/0x258
        [&lt;f965b9b6&gt;] netlink_sendmsg+0x1e8/0x428
        [&lt;aadb8231&gt;] ____sys_sendmsg+0x1e0/0x274
        [&lt;d2b5212d&gt;] ___sys_sendmsg+0x80/0xb4
However, since the kernel is build optimized, it seems the stack is not
accurate. It appears the issue is related to wfx_set_mfp_ap(). The issue
is obvious in this function: memory allocated by ieee80211_beacon_get()
is never released. Fixing this leak makes kmemleak happy.
CVE-2024-26897:In the Linux kernel, the following vulnerability has been resolved:
wifi: ath9k: delay all of ath9k_wmi_event_tasklet() until init is complete
The ath9k_wmi_event_tasklet() used in ath9k_htc assumes that all the data
structures have been fully initialised by the time it runs. However, because of
the order in which things are initialised, this is not guaranteed to be the
case, because the device is exposed to the USB subsystem before the ath9k driver
initialisation is completed.
We already committed a partial fix for this in commit:
8b3046abc99e (&quot;ath9k_htc: fix NULL pointer dereference at ath9k_htc_tx_get_packet()&quot;)
However, that commit only aborted the WMI_TXSTATUS_EVENTID command in the event
tasklet, pairing it with an &quot;initialisation complete&quot; bit in the TX struct. It
seems syzbot managed to trigger the race for one of the other commands as well,
so let's just move the existing synchronisation bit to cover the whole
tasklet (setting it at the end of ath9k_htc_probe_device() instead of inside
ath9k_tx_init()).
CVE-2024-26904:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-26910:In the Linux kernel, the following vulnerability has been resolved:
netfilter: ipset: fix performance regression in swap operation
The patch &quot;netfilter: ipset: fix race condition between swap/destroy
and kernel side add/del/test&quot;, commit 28628fa9 fixes a race condition.
But the synchronize_rcu() added to the swap function unnecessarily slows
it down: it can safely be moved to destroy and use call_rcu() instead.
Eric Dumazet pointed out that simply calling the destroy functions as
rcu callback does not work: sets with timeout use garbage collectors
which need cancelling at destroy which can wait. Therefore the destroy
functions are split into two: cancelling garbage collectors safely at
executing the command received by netlink and moving the remaining
part only into the rcu callback.
CVE-2024-26915:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Reset IH OVERFLOW_CLEAR bit
Allows us to detect subsequent IH ring buffer overflows as well.
CVE-2024-26922:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: validate the parameters of bo mapping operations more clearly
Verify the parameters of
amdgpu_vm_bo_(map/replace_map/clearing_mappings) in one common place.
CVE-2024-26924:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: do not free live element
Pablo reports a crash with large batches of elements with a
back-to-back add/remove pattern.  Quoting Pablo:
  add_elem(&quot;00000000&quot;) timeout 100 ms
  ...
  add_elem(&quot;0000000X&quot;) timeout 100 ms
  del_elem(&quot;0000000X&quot;) &lt;---------------- delete one that was just added
  ...
  add_elem(&quot;00005000&quot;) timeout 100 ms
  1) nft_pipapo_remove() removes element 0000000X
  Then, KASAN shows a splat.
Looking at the remove function there is a chance that we will drop a
rule that maps to a non-deactivated element.
Removal happens in two steps, first we do a lookup for key k and return the
to-be-removed element and mark it as inactive in the next generation.
Then, in a second step, the element gets removed from the set/map.
The _remove function does not work correctly if we have more than one
element that share the same key.
This can happen if we insert an element into a set when the set already
holds an element with same key, but the element mapping to the existing
key has timed out or is not active in the next generation.
In such case its possible that removal will unmap the wrong element.
If this happens, we will leak the non-deactivated element, it becomes
unreachable.
The element that got deactivated (and will be freed later) will
remain reachable in the set data structure, this can result in
a crash when such an element is retrieved during lookup (stale
pointer).
Add a check that the fully matching key does in fact map to the element
that we have marked as inactive in the deactivation step.
If not, we need to continue searching.
Add a bug/warn trap at the end of the function as well, the remove
function must not ever be called with an invisible/unreachable/non-existent
element.
v2: avoid uneeded temporary variable (Stefano)
CVE-2024-26925:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: release mutex after nft_gc_seq_end from abort path
The commit mutex should not be released during the critical section
between nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GC
worker could collect expired objects and get the released commit lock
within the same GC sequence.
nf_tables_module_autoload() temporarily releases the mutex to load
module dependencies, then it goes back to replay the transaction again.
Move it at the end of the abort phase after nft_gc_seq_end() is called.
CVE-2024-26926:In the Linux kernel, the following vulnerability has been resolved:
binder: check offset alignment in binder_get_object()
Commit 6d98eb95b450 (&quot;binder: avoid potential data leakage when copying
txn&quot;) introduced changes to how binder objects are copied. In doing so,
it unintentionally removed an offset alignment check done through calls
to binder_alloc_copy_from_buffer() -&gt; check_buffer().
These calls were replaced in binder_get_object() with copy_from_user(),
so now an explicit offset alignment check is needed here. This avoids
later complications when unwinding the objects gets harder.
It is worth noting this check existed prior to commit 7a67a39320df
(&quot;binder: add function to copy binder object from buffer&quot;), likely
removed due to redundancy at the time.
CVE-2024-26934:In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix deadlock in usb_deauthorize_interface()
Among the attribute file callback routines in
drivers/usb/core/sysfs.c, the interface_authorized_store() function is
the only one which acquires a device lock on an ancestor device: It
calls usb_deauthorize_interface(), which locks the interface's parent
USB device.
The will lead to deadlock if another process already owns that lock
and tries to remove the interface, whether through a configuration
change or because the device has been disconnected.  As part of the
removal procedure, device_del() waits for all ongoing sysfs attribute
callbacks to complete.  But usb_deauthorize_interface() can't complete
until the device lock has been released, and the lock won't be
released until the removal has finished.
The mechanism provided by sysfs to prevent this kind of deadlock is
to use the sysfs_break_active_protection() function, which tells sysfs
not to wait for the attribute callback.
Reported-and-tested by: Yue Sun &lt;samsun1006219@gmail.com&gt;
Reported by: xingwei lee &lt;xrivendell7@gmail.com&gt;
CVE-2024-26955:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: prevent kernel bug at submit_bh_wbc()
Fix a bug where nilfs_get_block() returns a successful status when
searching and inserting the specified block both fail inconsistently.  If
this inconsistent behavior is not due to a previously fixed bug, then an
unexpected race is occurring, so return a temporary error -EAGAIN instead.
This prevents callers such as __block_write_begin_int() from requesting a
read into a buffer that is not mapped, which would cause the BUG_ON check
for the BH_Mapped flag in submit_bh_wbc() to fail.
CVE-2024-26956:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix failure to detect DAT corruption in btree and direct mappings
Patch series &quot;nilfs2: fix kernel bug at submit_bh_wbc()&quot;.
This resolves a kernel BUG reported by syzbot.  Since there are two
flaws involved, I've made each one a separate patch.
The first patch alone resolves the syzbot-reported bug, but I think
both fixes should be sent to stable, so I've tagged them as such.
This patch (of 2):
Syzbot has reported a kernel bug in submit_bh_wbc() when writing file data
to a nilfs2 file system whose metadata is corrupted.
There are two flaws involved in this issue.
The first flaw is that when nilfs_get_block() locates a data block using
btree or direct mapping, if the disk address translation routine
nilfs_dat_translate() fails with internal code -ENOENT due to DAT metadata
corruption, it can be passed back to nilfs_get_block().  This causes
nilfs_get_block() to misidentify an existing block as non-existent,
causing both data block lookup and insertion to fail inconsistently.
The second flaw is that nilfs_get_block() returns a successful status in
this inconsistent state.  This causes the caller __block_write_begin_int()
or others to request a read even though the buffer is not mapped,
resulting in a BUG_ON check for the BH_Mapped flag in submit_bh_wbc()
failing.
This fixes the first issue by changing the return value to code -EINVAL
when a conversion using DAT fails with code -ENOENT, avoiding the
conflicting condition that leads to the kernel bug described above.  Here,
code -EINVAL indicates that metadata corruption was detected during the
block lookup, which will be properly handled as a file system error and
converted to -EIO when passing through the nilfs2 bmap layer.
CVE-2024-26960:In the Linux kernel, the following vulnerability has been resolved:
mm: swap: fix race between free_swap_and_cache() and swapoff()
There was previously a theoretical window where swapoff() could run and
teardown a swap_info_struct while a call to free_swap_and_cache() was
running in another thread.  This could cause, amongst other bad
possibilities, swap_page_trans_huge_swapped() (called by
free_swap_and_cache()) to access the freed memory for swap_map.
This is a theoretical problem and I haven't been able to provoke it from a
test case.  But there has been agreement based on code review that this is
possible (see link below).
Fix it by using get_swap_device()/put_swap_device(), which will stall
swapoff().  There was an extra check in _swap_info_get() to confirm that
the swap entry was not free.  This isn't present in get_swap_device()
because it doesn't make sense in general due to the race between getting
the reference and swapoff.  So I've added an equivalent check directly in
free_swap_and_cache().
Details of how to provoke one possible issue (thanks to David Hildenbrand
for deriving this):
--8&lt;-----
__swap_entry_free() might be the last user and result in
&quot;count == SWAP_HAS_CACHE&quot;.
swapoff-&gt;try_to_unuse() will stop as soon as soon as si-&gt;inuse_pages==0.
So the question is: could someone reclaim the folio and turn
si-&gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().
Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages are
still references by swap entries.
Process 1 still references subpage 0 via swap entry.
Process 2 still references subpage 1 via swap entry.
Process 1 quits. Calls free_swap_and_cache().
-&gt; count == SWAP_HAS_CACHE
[then, preempted in the hypervisor etc.]
Process 2 quits. Calls free_swap_and_cache().
-&gt; count == SWAP_HAS_CACHE
Process 2 goes ahead, passes swap_page_trans_huge_swapped(), and calls
__try_to_reclaim_swap().
__try_to_reclaim_swap()-&gt;folio_free_swap()-&gt;delete_from_swap_cache()-&gt;
put_swap_folio()-&gt;free_swap_slot()-&gt;swapcache_free_entries()-&gt;
swap_entry_free()-&gt;swap_range_free()-&gt;
...
WRITE_ONCE(si-&gt;inuse_pages, si-&gt;inuse_pages - nr_entries);
What stops swapoff to succeed after process 2 reclaimed the swap cache
but before process1 finished its call to swap_page_trans_huge_swapped()?
--8&lt;-----
CVE-2024-26966:In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: mmcc-apq8084: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
Only compile tested.
CVE-2024-26969:In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq8074: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
Only compile tested.
CVE-2024-26974:In the Linux kernel, the following vulnerability has been resolved:
crypto: qat - resolve race condition during AER recovery
During the PCI AER system's error recovery process, the kernel driver
may encounter a race condition with freeing the reset_data structure's
memory. If the device restart will take more than 10 seconds the function
scheduling that restart will exit due to a timeout, and the reset_data
structure will be freed. However, this data structure is used for
completion notification after the restart is completed, which leads
to a UAF bug.
This results in a KFENCE bug notice.
  BUG: KFENCE: use-after-free read in adf_device_reset_worker+0x38/0xa0 [intel_qat]
  Use-after-free read at 0x00000000bc56fddf (in kfence-#142):
  adf_device_reset_worker+0x38/0xa0 [intel_qat]
  process_one_work+0x173/0x340
To resolve this race condition, the memory associated to the container
of the work_struct is freed on the worker if the timeout expired,
otherwise on the function that schedules the worker.
The timeout detection can be done by checking if the caller is
still waiting for completion or not by using completion_done() function.
CVE-2024-26979:In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix possible null pointer derefence with invalid contexts
vmw_context_cotable can return either an error or a null pointer and its
usage sometimes went unchecked. Subsequent code would then try to access
either a null pointer or an error value.
The invalid dereferences were only possible with malformed userspace
apps which never properly initialized the rendering contexts.
Check the results of vmw_context_cotable to fix the invalid derefs.
Thanks:
ziming zhang(@ezrak1e) from Ant Group Light-Year Security Lab
who was the first person to discover it.
Niels De Graef who reported it and helped to track down the poc.
CVE-2024-26981:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix OOB in nilfs_set_de_type
The size of the nilfs_type_by_mode array in the fs/nilfs2/dir.c file is
defined as &quot;S_IFMT &gt;&gt; S_SHIFT&quot;, but the nilfs_set_de_type() function,
which uses this array, specifies the index to read from the array in the
same way as &quot;(mode &amp; S_IFMT) &gt;&gt; S_SHIFT&quot;.
static void nilfs_set_de_type(struct nilfs_dir_entry *de, struct inode
 *inode)
{
	umode_t mode = inode-&gt;i_mode;
	de-&gt;file_type = nilfs_type_by_mode[(mode &amp; S_IFMT)&gt;&gt;S_SHIFT]; // oob
}
However, when the index is determined this way, an out-of-bounds (OOB)
error occurs by referring to an index that is 1 larger than the array size
when the condition &quot;mode &amp; S_IFMT == S_IFMT&quot; is satisfied.  Therefore, a
patch to resize the nilfs_type_by_mode array should be applied to prevent
OOB errors.
CVE-2024-26984:In the Linux kernel, the following vulnerability has been resolved:
nouveau: fix instmem race condition around ptr stores
Running a lot of VK CTS in parallel against nouveau, once every
few hours you might see something like this crash.
BUG: kernel NULL pointer dereference, address: 0000000000000008
PGD 8000000114e6e067 P4D 8000000114e6e067 PUD 109046067 PMD 0
Oops: 0000 [#1] PREEMPT SMP PTI
CPU: 7 PID: 53891 Comm: deqp-vk Not tainted 6.8.0-rc6+ #27
Hardware name: Gigabyte Technology Co., Ltd. Z390 I AORUS PRO WIFI/Z390 I AORUS PRO WIFI-CF, BIOS F8 11/05/2021
RIP: 0010:gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
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
RSP: 0000:ffffac20c5857838 EFLAGS: 00010202
RAX: 0000000000000000 RBX: 00000000004d8001 RCX: 0000000000000001
RDX: 00000000004d8001 RSI: 00000000000006d8 RDI: ffffa07afe332180
RBP: 00000000000006d8 R08: ffffac20c5857ad0 R09: 0000000000ffff10
R10: 0000000000000001 R11: ffffa07af27e2de0 R12: 000000000000001c
R13: ffffac20c5857ad0 R14: ffffa07a96fe9040 R15: 000000000000001c
FS:  00007fe395eed7c0(0000) GS:ffffa07e2c980000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000008 CR3: 000000011febe001 CR4: 00000000003706f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
...
 ? gp100_vmm_pgt_mem+0xe3/0x180 [nouveau]
 ? gp100_vmm_pgt_mem+0x37/0x180 [nouveau]
 nvkm_vmm_iter+0x351/0xa20 [nouveau]
 ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 ? __lock_acquire+0x3ed/0x2170
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 nvkm_vmm_ptes_get_map+0xc2/0x100 [nouveau]
 ? __pfx_nvkm_vmm_ref_ptes+0x10/0x10 [nouveau]
 ? __pfx_gp100_vmm_pgt_mem+0x10/0x10 [nouveau]
 nvkm_vmm_map_locked+0x224/0x3a0 [nouveau]
Adding any sort of useful debug usually makes it go away, so I hand
wrote the function in a line, and debugged the asm.
Every so often pt-&gt;memory-&gt;ptrs is NULL. This ptrs ptr is set in
the nv50_instobj_acquire called from nvkm_kmap.
If Thread A and Thread B both get to nv50_instobj_acquire around
the same time, and Thread A hits the refcount_set line, and in
lockstep thread B succeeds at refcount_inc_not_zero, there is a
chance the ptrs value won't have been stored since refcount_set
is unordered. Force a memory barrier here, I picked smp_mb, since
we want it on all CPUs and it's write followed by a read.
v2: use paired smp_rmb/smp_wmb.
CVE-2024-26988:In the Linux kernel, the following vulnerability has been resolved:
init/main.c: Fix potential static_command_line memory overflow
We allocate memory of size 'xlen + strlen(boot_command_line) + 1' for
static_command_line, but the strings copied into static_command_line are
extra_command_line and command_line, rather than extra_command_line and
boot_command_line.
When strlen(command_line) &gt; strlen(boot_command_line), static_command_line
will overflow.
This patch just recovers strlen(command_line) which was miss-consolidated
with strlen(boot_command_line) in the commit f5c7310ac73e (&quot;init/main: add
checks for the return value of memblock_alloc*()&quot;)
CVE-2024-26994:In the Linux kernel, the following vulnerability has been resolved:
speakup: Avoid crash on very long word
In case a console is set up really large and contains a really long word
(&gt; 256 characters), we have to stop before the length of the word buffer.
CVE-2024-26996:In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: Fix UAF ncm object at re-bind after usb ep transport error
When ncm function is working and then stop usb0 interface for link down,
eth_stop() is called. At this piont, accidentally if usb transport error
should happen in usb_ep_enable(), 'in_ep' and/or 'out_ep' may not be enabled.
After that, ncm_disable() is called to disable for ncm unbind
but gether_disconnect() is never called since 'in_ep' is not enabled.
As the result, ncm object is released in ncm unbind
but 'dev-&gt;port_usb' associated to 'ncm-&gt;port' is not NULL.
And when ncm bind again to recover netdev, ncm object is reallocated
but usb0 interface is already associated to previous released ncm object.
Therefore, once usb0 interface is up and eth_start_xmit() is called,
released ncm object is dereferrenced and it might cause use-after-free memory.
[function unlink via configfs]
  usb0: eth_stop dev-&gt;port_usb=ffffff9b179c3200
  --&gt; error happens in usb_ep_enable().
  NCM: ncm_disable: ncm=ffffff9b179c3200
  --&gt; no gether_disconnect() since ncm-&gt;port.in_ep-&gt;enabled is false.
  NCM: ncm_unbind: ncm unbind ncm=ffffff9b179c3200
  NCM: ncm_free: ncm free ncm=ffffff9b179c3200   &lt;-- released ncm
[function link via configfs]
  NCM: ncm_alloc: ncm alloc ncm=ffffff9ac4f8a000
  NCM: ncm_bind: ncm bind ncm=ffffff9ac4f8a000
  NCM: ncm_set_alt: ncm=ffffff9ac4f8a000 alt=0
  usb0: eth_open dev-&gt;port_usb=ffffff9b179c3200  &lt;-- previous released ncm
  usb0: eth_start dev-&gt;port_usb=ffffff9b179c3200 &lt;--
  eth_start_xmit()
  --&gt; dev-&gt;wrap()
  Unable to handle kernel paging request at virtual address dead00000000014f
This patch addresses the issue by checking if 'ncm-&gt;netdev' is not NULL at
ncm_disable() to call gether_disconnect() to deassociate 'dev-&gt;port_usb'.
It's more reasonable to check 'ncm-&gt;netdev' to call gether_connect/disconnect
rather than check 'ncm-&gt;port.in_ep-&gt;enabled' since it might not be enabled
but the gether connection might be established.
CVE-2024-26999:In the Linux kernel, the following vulnerability has been resolved:
serial/pmac_zilog: Remove flawed mitigation for rx irq flood
The mitigation was intended to stop the irq completely. That may be
better than a hard lock-up but it turns out that you get a crash anyway
if you're using pmac_zilog as a serial console:
ttyPZ0: pmz: rx irq flood !
BUG: spinlock recursion on CPU#0, swapper/0
That's because the pr_err() call in pmz_receive_chars() results in
pmz_console_write() attempting to lock a spinlock already locked in
pmz_interrupt(). With CONFIG_DEBUG_SPINLOCK=y, this produces a fatal
BUG splat. The spinlock in question is the one in struct uart_port.
Even when it's not fatal, the serial port rx function ceases to work.
Also, the iteration limit doesn't play nicely with QEMU, as can be
seen in the bug report linked below.
A web search for other reports of the error message &quot;pmz: rx irq flood&quot;
didn't produce anything. So I don't think this code is needed any more.
Remove it.
CVE-2024-27001:In the Linux kernel, the following vulnerability has been resolved:
comedi: vmk80xx: fix incomplete endpoint checking
While vmk80xx does have endpoint checking implemented, some things
can fall through the cracks. Depending on the hardware model,
URBs can have either bulk or interrupt type, and current version
of vmk80xx_find_usb_endpoints() function does not take that fully
into account. While this warning does not seem to be too harmful,
at the very least it will crash systems with 'panic_on_warn' set on
them.
Fix the issue found by Syzkaller [1] by somewhat simplifying the
endpoint checking process with usb_find_common_endpoints() and
ensuring that only expected endpoint types are present.
This patch has not been tested on real hardware.
[1] Syzkaller report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 781 at drivers/usb/core/urb.c:504 usb_submit_urb+0xc4e/0x18c0 drivers/usb/core/urb.c:503
...
Call Trace:
 &lt;TASK&gt;
 usb_start_wait_urb+0x113/0x520 drivers/usb/core/message.c:59
 vmk80xx_reset_device drivers/comedi/drivers/vmk80xx.c:227 [inline]
 vmk80xx_auto_attach+0xa1c/0x1a40 drivers/comedi/drivers/vmk80xx.c:818
 comedi_auto_config+0x238/0x380 drivers/comedi/drivers.c:1067
 usb_probe_interface+0x5cd/0xb00 drivers/usb/core/driver.c:399
...
Similar issue also found by Syzkaller:
CVE-2024-27004:In the Linux kernel, the following vulnerability has been resolved:
clk: Get runtime PM before walking tree during disable_unused
Doug reported [1] the following hung task:
 INFO: task swapper/0:1 blocked for more than 122 seconds.
       Not tainted 5.15.149-21875-gf795ebc40eb8 #1
 &quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
 task:swapper/0       state:D stack:    0 pid:    1 ppid:     0 flags:0x00000008
 Call trace:
  __switch_to+0xf4/0x1f4
  __schedule+0x418/0xb80
  schedule+0x5c/0x10c
  rpm_resume+0xe0/0x52c
  rpm_resume+0x178/0x52c
  __pm_runtime_resume+0x58/0x98
  clk_pm_runtime_get+0x30/0xb0
  clk_disable_unused_subtree+0x58/0x208
  clk_disable_unused_subtree+0x38/0x208
  clk_disable_unused_subtree+0x38/0x208
  clk_disable_unused_subtree+0x38/0x208
  clk_disable_unused_subtree+0x38/0x208
  clk_disable_unused+0x4c/0xe4
  do_one_initcall+0xcc/0x2d8
  do_initcall_level+0xa4/0x148
  do_initcalls+0x5c/0x9c
  do_basic_setup+0x24/0x30
  kernel_init_freeable+0xec/0x164
  kernel_init+0x28/0x120
  ret_from_fork+0x10/0x20
 INFO: task kworker/u16:0:9 blocked for more than 122 seconds.
       Not tainted 5.15.149-21875-gf795ebc40eb8 #1
 &quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
 task:kworker/u16:0   state:D stack:    0 pid:    9 ppid:     2 flags:0x00000008
 Workqueue: events_unbound deferred_probe_work_func
 Call trace:
  __switch_to+0xf4/0x1f4
  __schedule+0x418/0xb80
  schedule+0x5c/0x10c
  schedule_preempt_disabled+0x2c/0x48
  __mutex_lock+0x238/0x488
  __mutex_lock_slowpath+0x1c/0x28
  mutex_lock+0x50/0x74
  clk_prepare_lock+0x7c/0x9c
  clk_core_prepare_lock+0x20/0x44
  clk_prepare+0x24/0x30
  clk_bulk_prepare+0x40/0xb0
  mdss_runtime_resume+0x54/0x1c8
  pm_generic_runtime_resume+0x30/0x44
  __genpd_runtime_resume+0x68/0x7c
  genpd_runtime_resume+0x108/0x1f4
  __rpm_callback+0x84/0x144
  rpm_callback+0x30/0x88
  rpm_resume+0x1f4/0x52c
  rpm_resume+0x178/0x52c
  __pm_runtime_resume+0x58/0x98
  __device_attach+0xe0/0x170
  device_initial_probe+0x1c/0x28
  bus_probe_device+0x3c/0x9c
  device_add+0x644/0x814
  mipi_dsi_device_register_full+0xe4/0x170
  devm_mipi_dsi_device_register_full+0x28/0x70
  ti_sn_bridge_probe+0x1dc/0x2c0
  auxiliary_bus_probe+0x4c/0x94
  really_probe+0xcc/0x2c8
  __driver_probe_device+0xa8/0x130
  driver_probe_device+0x48/0x110
  __device_attach_driver+0xa4/0xcc
  bus_for_each_drv+0x8c/0xd8
  __device_attach+0xf8/0x170
  device_initial_probe+0x1c/0x28
  bus_probe_device+0x3c/0x9c
  deferred_probe_work_func+0x9c/0xd8
  process_one_work+0x148/0x518
  worker_thread+0x138/0x350
  kthread+0x138/0x1e0
  ret_from_fork+0x10/0x20
The first thread is walking the clk tree and calling
clk_pm_runtime_get() to power on devices required to read the clk
hardware via struct clk_ops::is_enabled(). This thread holds the clk
prepare_lock, and is trying to runtime PM resume a device, when it finds
that the device is in the process of resuming so the thread schedule()s
away waiting for the device to finish resuming before continuing. The
second thread is runtime PM resuming the same device, but the runtime
resume callback is calling clk_prepare(), trying to grab the
prepare_lock waiting on the first thread.
This is a classic ABBA deadlock. To properly fix the deadlock, we must
never runtime PM resume or suspend a device with the clk prepare_lock
held. Actually doing that is near impossible today because the global
prepare_lock would have to be dropped in the middle of the tree, the
device runtime PM resumed/suspended, and then the prepare_lock grabbed
again to ensure consistency of the clk tree topology. If anything
changes with the clk tree in the meantime, we've lost and will need to
start the operation all over again.
Luckily, most of the time we're simply incrementing or decrementing the
runtime PM count on an active device, so we don't have the chance to
schedule away with the prepare_lock held. Let's fix this immediate
problem that can be
---truncated---
CVE-2024-27010:In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix mirred deadlock on device recursion
When the mirred action is used on a classful egress qdisc and a packet is
mirrored or redirected to self we hit a qdisc lock deadlock.
See trace below.
[..... other info removed for brevity....]
[   82.890906]
[   82.890906] ============================================
[   82.890906] WARNING: possible recursive locking detected
[   82.890906] 6.8.0-05205-g77fadd89fe2d-dirty #213 Tainted: G        W
[   82.890906] --------------------------------------------
[   82.890906] ping/418 is trying to acquire lock:
[   82.890906] ffff888006994110 (&amp;sch-&gt;q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[   82.890906]
[   82.890906] but task is already holding lock:
[   82.890906] ffff888006994110 (&amp;sch-&gt;q.lock){+.-.}-{3:3}, at:
__dev_queue_xmit+0x1778/0x3550
[   82.890906]
[   82.890906] other info that might help us debug this:
[   82.890906]  Possible unsafe locking scenario:
[   82.890906]
[   82.890906]        CPU0
[   82.890906]        ----
[   82.890906]   lock(&amp;sch-&gt;q.lock);
[   82.890906]   lock(&amp;sch-&gt;q.lock);
[   82.890906]
[   82.890906]  *** DEADLOCK ***
[   82.890906]
[..... other info removed for brevity....]
Example setup (eth0-&gt;eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth0
Another example(eth0-&gt;eth1-&gt;eth0) to recreate
tc qdisc add dev eth0 root handle 1: htb default 30
tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth1
tc qdisc add dev eth1 root handle 1: htb default 30
tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \
     action mirred egress redirect dev eth0
We fix this by adding an owner field (CPU id) to struct Qdisc set after
root qdisc is entered. When the softirq enters it a second time, if the
qdisc owner is the same CPU, the packet is dropped to break the loop.
CVE-2024-27011:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: fix memleak in map from abort path
The delete set command does not rely on the transaction object for
element removal, therefore, a combination of delete element + delete set
from the abort path could result in restoring twice the refcount of the
mapping.
Check for inactive element in the next generation for the delete element
command in the abort path, skip restoring state if next generation bit
has been already cleared. This is similar to the activate logic using
the set walk iterator.
[ 6170.286929] ------------[ cut here ]------------
[ 6170.286939] WARNING: CPU: 6 PID: 790302 at net/netfilter/nf_tables_api.c:2086 nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.287071] Modules linked in: [...]
[ 6170.287633] CPU: 6 PID: 790302 Comm: kworker/6:2 Not tainted 6.9.0-rc3+ #365
[ 6170.287768] RIP: 0010:nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 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
[ 6170.287895] RSP: 0018:ffff888134b8fd08 EFLAGS: 00010202
[ 6170.287904] RAX: 0000000000000001 RBX: ffff888125bffb28 RCX: dffffc0000000000
[ 6170.287912] RDX: 0000000000000003 RSI: ffffffffa20298ab RDI: ffff88811ebe4750
[ 6170.287919] RBP: ffff88811ebe4700 R08: ffff88838e812650 R09: fffffbfff0623a55
[ 6170.287926] R10: ffffffff8311d2af R11: 0000000000000001 R12: ffff888125bffb10
[ 6170.287933] R13: ffff888125bffb10 R14: dead000000000122 R15: dead000000000100
[ 6170.287940] FS:  0000000000000000(0000) GS:ffff888390b00000(0000) knlGS:0000000000000000
[ 6170.287948] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6170.287955] CR2: 00007fd31fc00710 CR3: 0000000133f60004 CR4: 00000000001706f0
[ 6170.287962] Call Trace:
[ 6170.287967]  &lt;TASK&gt;
[ 6170.287973]  ? __warn+0x9f/0x1a0
[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092]  ? report_bug+0x1b1/0x1e0
[ 6170.287986]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288092]  ? report_bug+0x1b1/0x1e0
[ 6170.288104]  ? handle_bug+0x3c/0x70
[ 6170.288112]  ? exc_invalid_op+0x17/0x40
[ 6170.288120]  ? asm_exc_invalid_op+0x1a/0x20
[ 6170.288132]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288243]  ? nf_tables_chain_destroy+0x1f7/0x220 [nf_tables]
[ 6170.288366]  ? nf_tables_chain_destroy+0x2b/0x220 [nf_tables]
[ 6170.288483]  nf_tables_trans_destroy_work+0x588/0x590 [nf_tables]
CVE-2024-27014:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Prevent deadlock while disabling aRFS
When disabling aRFS under the `priv-&gt;state_lock`, any scheduled
aRFS works are canceled using the `cancel_work_sync` function,
which waits for the work to end if it has already started.
However, while waiting for the work handler, the handler will
try to acquire the `state_lock` which is already acquired.
The worker acquires the lock to delete the rules if the state
is down, which is not the worker's responsibility since
disabling aRFS deletes the rules.
Add an aRFS state variable, which indicates whether the aRFS is
enabled and prevent adding rules when the aRFS is disabled.
Kernel log:
======================================================
WARNING: possible circular locking dependency detected
6.7.0-rc4_net_next_mlx5_5483eb2 #1 Tainted: G          I
------------------------------------------------------
ethtool/386089 is trying to acquire lock:
ffff88810f21ce68 ((work_completion)(&amp;rule-&gt;arfs_work)){+.+.}-{0:0}, at: __flush_work+0x74/0x4e0
but task is already holding lock:
ffff8884a1808cc0 (&amp;priv-&gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-&gt; #1 (&amp;priv-&gt;state_lock){+.+.}-{3:3}:
       __mutex_lock+0x80/0xc90
       arfs_handle_work+0x4b/0x3b0 [mlx5_core]
       process_one_work+0x1dc/0x4a0
       worker_thread+0x1bf/0x3c0
       kthread+0xd7/0x100
       ret_from_fork+0x2d/0x50
       ret_from_fork_asm+0x11/0x20
-&gt; #0 ((work_completion)(&amp;rule-&gt;arfs_work)){+.+.}-{0:0}:
       __lock_acquire+0x17b4/0x2c80
       lock_acquire+0xd0/0x2b0
       __flush_work+0x7a/0x4e0
       __cancel_work_timer+0x131/0x1c0
       arfs_del_rules+0x143/0x1e0 [mlx5_core]
       mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
       mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
       ethnl_set_channels+0x28f/0x3b0
       ethnl_default_set_doit+0xec/0x240
       genl_family_rcv_msg_doit+0xd0/0x120
       genl_rcv_msg+0x188/0x2c0
       netlink_rcv_skb+0x54/0x100
       genl_rcv+0x24/0x40
       netlink_unicast+0x1a1/0x270
       netlink_sendmsg+0x214/0x460
       __sock_sendmsg+0x38/0x60
       __sys_sendto+0x113/0x170
       __x64_sys_sendto+0x20/0x30
       do_syscall_64+0x40/0xe0
       entry_SYSCALL_64_after_hwframe+0x46/0x4e
other info that might help us debug this:
 Possible unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(&amp;priv-&gt;state_lock);
                               lock((work_completion)(&amp;rule-&gt;arfs_work));
                               lock(&amp;priv-&gt;state_lock);
  lock((work_completion)(&amp;rule-&gt;arfs_work));
 *** DEADLOCK ***
3 locks held by ethtool/386089:
 #0: ffffffff82ea7210 (cb_lock){++++}-{3:3}, at: genl_rcv+0x15/0x40
 #1: ffffffff82e94c88 (rtnl_mutex){+.+.}-{3:3}, at: ethnl_default_set_doit+0xd3/0x240
 #2: ffff8884a1808cc0 (&amp;priv-&gt;state_lock){+.+.}-{3:3}, at: mlx5e_ethtool_set_channels+0x53/0x200 [mlx5_core]
stack backtrace:
CPU: 15 PID: 386089 Comm: ethtool Tainted: G          I        6.7.0-rc4_net_next_mlx5_5483eb2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x60/0xa0
 check_noncircular+0x144/0x160
 __lock_acquire+0x17b4/0x2c80
 lock_acquire+0xd0/0x2b0
 ? __flush_work+0x74/0x4e0
 ? save_trace+0x3e/0x360
 ? __flush_work+0x74/0x4e0
 __flush_work+0x7a/0x4e0
 ? __flush_work+0x74/0x4e0
 ? __lock_acquire+0xa78/0x2c80
 ? lock_acquire+0xd0/0x2b0
 ? mark_held_locks+0x49/0x70
 __cancel_work_timer+0x131/0x1c0
 ? mark_held_locks+0x49/0x70
 arfs_del_rules+0x143/0x1e0 [mlx5_core]
 mlx5e_arfs_disable+0x1b/0x30 [mlx5_core]
 mlx5e_ethtool_set_channels+0xcb/0x200 [mlx5_core]
 ethnl_set_channels+0x28f/0x3b0
 ethnl_default_set_doit+0xec/0x240
 genl_family_rcv_msg_doit+0xd0/0x120
 genl_rcv_msg+0x188/0x2c0
 ? ethn
---truncated---
CVE-2024-27019:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_obj_type_get()
nft_unregister_obj() can concurrent with __nft_obj_type_get(),
and there is not any protection when iterate over nf_tables_objects
list in __nft_obj_type_get(). Therefore, there is potential data-race
of nf_tables_objects list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_objects
list in __nft_obj_type_get(), and use rcu_read_lock() in the caller
nft_obj_type_get() to protect the entire type query process.
CVE-2024-27020:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_expr_type_get()
nft_unregister_expr() can concurrent with __nft_expr_type_get(),
and there is not any protection when iterate over nf_tables_expressions
list in __nft_expr_type_get(). Therefore, there is potential data-race
of nf_tables_expressions list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_expressions
list in __nft_expr_type_get(), and use rcu_read_lock() in the caller
nft_expr_type_get() to protect the entire type query process.
CVE-2024-27028:In the Linux kernel, the following vulnerability has been resolved:
spi: spi-mt65xx: Fix NULL pointer access in interrupt handler
The TX buffer in spi_transfer can be a NULL pointer, so the interrupt
handler may end up writing to the invalid memory and cause crashes.
Add a check to trans-&gt;tx_buf before using it.
CVE-2024-27030:In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: Use separate handlers for interrupts
For PF to AF interrupt vector and VF to AF vector same
interrupt handler is registered which is causing race condition.
When two interrupts are raised to two CPUs at same time
then two cores serve same event corrupting the data.
CVE-2024-27032:In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to avoid potential panic during recovery
During recovery, if FAULT_BLOCK is on, it is possible that
f2fs_reserve_new_block() will return -ENOSPC during recovery,
then it may trigger panic.
Also, if fault injection rate is 1 and only FAULT_BLOCK fault
type is on, it may encounter deadloop in loop of block reservation.
Let's change as below to fix these issues:
- remove bug_on() to avoid panic.
- limit the loop count of block reservation to avoid potential
deadloop.
CVE-2024-27034:In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix to cover normal cluster write with cp_rwsem
When we overwrite compressed cluster w/ normal cluster, we should
not unlock cp_rwsem during f2fs_write_raw_pages(), otherwise data
will be corrupted if partial blocks were persisted before CP &amp; SPOR,
due to cluster metadata wasn't updated atomically.
CVE-2024-27035:In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix to guarantee persisting compressed blocks by CP
If data block in compressed cluster is not persisted with metadata
during checkpoint, after SPOR, the data may be corrupted, let's
guarantee to write compressed page by checkpoint.
CVE-2024-27037:In the Linux kernel, the following vulnerability has been resolved:
clk: zynq: Prevent null pointer dereference caused by kmalloc failure
The kmalloc() in zynq_clk_setup() will return null if the
physical memory has run out. As a result, if we use snprintf()
to write data to the null address, the null pointer dereference
bug will happen.
This patch uses a stack variable to replace the kmalloc().
CVE-2024-27038:In the Linux kernel, the following vulnerability has been resolved:
clk: Fix clk_core_get NULL dereference
It is possible for clk_core_get to dereference a NULL in the following
sequence:
clk_core_get()
    of_clk_get_hw_from_clkspec()
        __of_clk_get_hw_from_provider()
            __clk_get_hw()
__clk_get_hw() can return NULL which is dereferenced by clk_core_get() at
hw-&gt;core.
Prior to commit dde4eff47c82 (&quot;clk: Look for parents with clkdev based
clk_lookups&quot;) the check IS_ERR_OR_NULL() was performed which would have
caught the NULL.
Reading the description of this function it talks about returning NULL but
that cannot be so at the moment.
Update the function to check for hw before dereferencing it and return NULL
if hw is NULL.
CVE-2024-27046:In the Linux kernel, the following vulnerability has been resolved:
nfp: flower: handle acti_netdevs allocation failure
The kmalloc_array() in nfp_fl_lag_do_work() will return null, if
the physical memory has run out. As a result, if we dereference
the acti_netdevs, the null pointer dereference bugs will happen.
This patch adds a check to judge whether allocation failure occurs.
If it happens, the delayed work will be rescheduled and try again.
CVE-2024-27051:In the Linux kernel, the following vulnerability has been resolved:
cpufreq: brcmstb-avs-cpufreq: add check for cpufreq_cpu_get's return value
cpufreq_cpu_get may return NULL. To avoid NULL-dereference check it
and return 0 in case of error.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-27053:In the Linux kernel, the following vulnerability has been resolved:
wifi: wilc1000: fix RCU usage in connect path
With lockdep enabled, calls to the connect function from cfg802.11 layer
lead to the following warning:
=============================
WARNING: suspicious RCU usage
6.7.0-rc1-wt+ #333 Not tainted
-----------------------------
drivers/net/wireless/microchip/wilc1000/hif.c:386
suspicious rcu_dereference_check() usage!
[...]
stack backtrace:
CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333
Hardware name: Atmel SAMA5
 unwind_backtrace from show_stack+0x18/0x1c
 show_stack from dump_stack_lvl+0x34/0x48
 dump_stack_lvl from wilc_parse_join_bss_param+0x7dc/0x7f4
 wilc_parse_join_bss_param from connect+0x2c4/0x648
 connect from cfg80211_connect+0x30c/0xb74
 cfg80211_connect from nl80211_connect+0x860/0xa94
 nl80211_connect from genl_rcv_msg+0x3fc/0x59c
 genl_rcv_msg from netlink_rcv_skb+0xd0/0x1f8
 netlink_rcv_skb from genl_rcv+0x2c/0x3c
 genl_rcv from netlink_unicast+0x3b0/0x550
 netlink_unicast from netlink_sendmsg+0x368/0x688
 netlink_sendmsg from ____sys_sendmsg+0x190/0x430
 ____sys_sendmsg from ___sys_sendmsg+0x110/0x158
 ___sys_sendmsg from sys_sendmsg+0xe8/0x150
 sys_sendmsg from ret_fast_syscall+0x0/0x1c
This warning is emitted because in the connect path, when trying to parse
target BSS parameters, we dereference a RCU pointer whithout being in RCU
critical section.
Fix RCU dereference usage by moving it to a RCU read critical section. To
avoid wrapping the whole wilc_parse_join_bss_param under the critical
section, just use the critical section to copy ies data
CVE-2024-27054:In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: fix double module refcount decrement
Once the discipline is associated with the device, deleting the device
takes care of decrementing the module's refcount.  Doing it manually on
this error path causes refcount to artificially decrease on each error
while it should just stay the same.
CVE-2024-27074:In the Linux kernel, the following vulnerability has been resolved:
media: go7007: fix a memleak in go7007_load_encoder
In go7007_load_encoder, bounce(i.e. go-&gt;boot_fw), is allocated without
a deallocation thereafter. After the following call chain:
saa7134_go7007_init
  |-&gt; go7007_boot_encoder
        |-&gt; go7007_load_encoder
  |-&gt; kfree(go)
go is freed and thus bounce is leaked.
CVE-2024-27077:In the Linux kernel, the following vulnerability has been resolved:
media: v4l2-mem2mem: fix a memleak in v4l2_m2m_register_entity
The entity-&gt;name (i.e. name) is allocated in v4l2_m2m_register_entity
but isn't freed in its following error-handling paths. This patch
adds such deallocation to prevent memleak of entity-&gt;name.
CVE-2024-35935:In the Linux kernel, the following vulnerability has been resolved:
btrfs: send: handle path ref underflow in header iterate_inode_ref()
Change BUG_ON to proper error handling if building the path buffer
fails. The pointers are not printed so we don't accidentally leak kernel
addresses.
CVE-2024-35973:In the Linux kernel, the following vulnerability has been resolved:
geneve: fix header validation in geneve[6]_xmit_skb
syzbot is able to trigger an uninit-value in geneve_xmit() [1]
Problem : While most ip tunnel helpers (like ip_tunnel_get_dsfield())
uses skb_protocol(skb, true), pskb_inet_may_pull() is only using
skb-&gt;protocol.
If anything else than ETH_P_IPV6 or ETH_P_IP is found in skb-&gt;protocol,
pskb_inet_may_pull() does nothing at all.
If a vlan tag was provided by the caller (af_packet in the syzbot case),
the network header might not point to the correct location, and skb
linear part could be smaller than expected.
Add skb_vlan_inet_prepare() to perform a complete mac validation.
Use this in geneve for the moment, I suspect we need to adopt this
more broadly.
v4 - Jakub reported v3 broke l2_tos_ttl_inherit.sh selftest
   - Only call __vlan_get_protocol() for vlan types.
v2,v3 - Addressed Sabrina comments on v1 and v2
[1]
BUG: KMSAN: uninit-value in geneve_xmit_skb drivers/net/geneve.c:910 [inline]
 BUG: KMSAN: uninit-value in geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  geneve_xmit_skb drivers/net/geneve.c:910 [inline]
  geneve_xmit+0x302d/0x5420 drivers/net/geneve.c:1030
  __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
  netdev_start_xmit include/linux/netdevice.h:4917 [inline]
  xmit_one net/core/dev.c:3531 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
  __dev_queue_xmit+0x348d/0x52c0 net/core/dev.c:4335
  dev_queue_xmit include/linux/netdevice.h:3091 [inline]
  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3081 [inline]
  packet_sendmsg+0x8bb0/0x9ef0 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3804 [inline]
  slab_alloc_node mm/slub.c:3845 [inline]
  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
  alloc_skb include/linux/skbuff.h:1318 [inline]
  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
  packet_alloc_skb net/packet/af_packet.c:2930 [inline]
  packet_snd net/packet/af_packet.c:3024 [inline]
  packet_sendmsg+0x722d/0x9ef0 net/packet/af_packet.c:3113
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2191
  __do_sys_sendto net/socket.c:2203 [inline]
  __se_sys_sendto net/socket.c:2199 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2199
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
CVE-2024-35978:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix memory leak in hci_req_sync_complete()
In 'hci_req_sync_complete()', always free the previous sync
request state before assigning reference to a new one.
CVE-2024-35982:In the Linux kernel, the following vulnerability has been resolved:
batman-adv: Avoid infinite loop trying to resize local TT
If the MTU of one of an attached interface becomes too small to transmit
the local translation table then it must be resized to fit inside all
fragments (when enabled) or a single packet.
But if the MTU becomes too low to transmit even the header + the VLAN
specific part then the resizing of the local TT will never succeed. This
can for example happen when the usable space is 110 bytes and 11 VLANs are
on top of batman-adv. In this case, at least 116 byte would be needed.
There will just be an endless spam of
   batman_adv: batadv0: Forced to purge local tt entries to fit new maximum fragment MTU (110)
in the log but the function will never finish. Problem here is that the
timeout will be halved all the time and will then stagnate at 0 and
therefore never be able to reduce the table even more.
There are other scenarios possible with a similar result. The number of
BATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be too
high to fit inside a packet. Such a scenario can therefore happen also with
only a single VLAN + 7 non-purgable addresses - requiring at least 120
bytes.
While this should be handled proactively when:
* interface with too low MTU is added
* VLAN is added
* non-purgeable local mac is added
* MTU of an attached interface is reduced
* fragmentation setting gets disabled (which most likely requires dropping
  attached interfaces)
not all of these scenarios can be prevented because batman-adv is only
consuming events without the the possibility to prevent these actions
(non-purgable MAC address added, MTU of an attached interface is reduced).
It is therefore necessary to also make sure that the code is able to handle
also the situations when there were already incompatible system
configuration are present.
CVE-2024-35984:In the Linux kernel, the following vulnerability has been resolved:
i2c: smbus: fix NULL function pointer dereference
Baruch reported an OOPS when using the designware controller as target
only. Target-only modes break the assumption of one transfer function
always being available. Fix this by always checking the pointer in
__i2c_transfer.
[wsa: dropped the simplification in core-smbus to avoid theoretical regressions]
CVE-2024-35990:In the Linux kernel, the following vulnerability has been resolved:
dma: xilinx_dpdma: Fix locking
There are several places where either chan-&gt;lock or chan-&gt;vchan.lock was
not held. Add appropriate locking. This fixes lockdep warnings like
[   31.077578] ------------[ cut here ]------------
[   31.077831] WARNING: CPU: 2 PID: 40 at drivers/dma/xilinx/xilinx_dpdma.c:834 xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[   31.077953] Modules linked in:
[   31.078019] CPU: 2 PID: 40 Comm: kworker/u12:1 Not tainted 6.6.20+ #98
[   31.078102] Hardware name: xlnx,zynqmp (DT)
[   31.078169] Workqueue: events_unbound deferred_probe_work_func
[   31.078272] pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   31.078377] pc : xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[   31.078473] lr : xilinx_dpdma_chan_queue_transfer+0x270/0x5e0
[   31.078550] sp : ffffffc083bb2e10
[   31.078590] x29: ffffffc083bb2e10 x28: 0000000000000000 x27: ffffff880165a168
[   31.078754] x26: ffffff880164e920 x25: ffffff880164eab8 x24: ffffff880164d480
[   31.078920] x23: ffffff880165a148 x22: ffffff880164e988 x21: 0000000000000000
[   31.079132] x20: ffffffc082aa3000 x19: ffffff880164e880 x18: 0000000000000000
[   31.079295] x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
[   31.079453] x14: 0000000000000000 x13: ffffff8802263dc0 x12: 0000000000000001
[   31.079613] x11: 0001ffc083bb2e34 x10: 0001ff880164e98f x9 : 0001ffc082aa3def
[   31.079824] x8 : 0001ffc082aa3dec x7 : 0000000000000000 x6 : 0000000000000516
[   31.079982] x5 : ffffffc7f8d43000 x4 : ffffff88003c9c40 x3 : ffffffffffffffff
[   31.080147] x2 : ffffffc7f8d43000 x1 : 00000000000000c0 x0 : 0000000000000000
[   31.080307] Call trace:
[   31.080340]  xilinx_dpdma_chan_queue_transfer+0x274/0x5e0
[   31.080518]  xilinx_dpdma_issue_pending+0x11c/0x120
[   31.080595]  zynqmp_disp_layer_update+0x180/0x3ac
[   31.080712]  zynqmp_dpsub_plane_atomic_update+0x11c/0x21c
[   31.080825]  drm_atomic_helper_commit_planes+0x20c/0x684
[   31.080951]  drm_atomic_helper_commit_tail+0x5c/0xb0
[   31.081139]  commit_tail+0x234/0x294
[   31.081246]  drm_atomic_helper_commit+0x1f8/0x210
[   31.081363]  drm_atomic_commit+0x100/0x140
[   31.081477]  drm_client_modeset_commit_atomic+0x318/0x384
[   31.081634]  drm_client_modeset_commit_locked+0x8c/0x24c
[   31.081725]  drm_client_modeset_commit+0x34/0x5c
[   31.081812]  __drm_fb_helper_restore_fbdev_mode_unlocked+0x104/0x168
[   31.081899]  drm_fb_helper_set_par+0x50/0x70
[   31.081971]  fbcon_init+0x538/0xc48
[   31.082047]  visual_init+0x16c/0x23c
[   31.082207]  do_bind_con_driver.isra.0+0x2d0/0x634
[   31.082320]  do_take_over_console+0x24c/0x33c
[   31.082429]  do_fbcon_takeover+0xbc/0x1b0
[   31.082503]  fbcon_fb_registered+0x2d0/0x34c
[   31.082663]  register_framebuffer+0x27c/0x38c
[   31.082767]  __drm_fb_helper_initial_config_and_unlock+0x5c0/0x91c
[   31.082939]  drm_fb_helper_initial_config+0x50/0x74
[   31.083012]  drm_fbdev_dma_client_hotplug+0xb8/0x108
[   31.083115]  drm_client_register+0xa0/0xf4
[   31.083195]  drm_fbdev_dma_setup+0xb0/0x1cc
[   31.083293]  zynqmp_dpsub_drm_init+0x45c/0x4e0
[   31.083431]  zynqmp_dpsub_probe+0x444/0x5e0
[   31.083616]  platform_probe+0x8c/0x13c
[   31.083713]  really_probe+0x258/0x59c
[   31.083793]  __driver_probe_device+0xc4/0x224
[   31.083878]  driver_probe_device+0x70/0x1c0
[   31.083961]  __device_attach_driver+0x108/0x1e0
[   31.084052]  bus_for_each_drv+0x9c/0x100
[   31.084125]  __device_attach+0x100/0x298
[   31.084207]  device_initial_probe+0x14/0x20
[   31.084292]  bus_probe_device+0xd8/0xdc
[   31.084368]  deferred_probe_work_func+0x11c/0x180
[   31.084451]  process_one_work+0x3ac/0x988
[   31.084643]  worker_thread+0x398/0x694
[   31.084752]  kthread+0x1bc/0x1c0
[   31.084848]  ret_from_fork+0x10/0x20
[   31.084932] irq event stamp: 64549
[   31.084970] hardirqs last  enabled at (64548): [&lt;ffffffc081adf35c&gt;] _raw_spin_unlock_irqrestore+0x80/0x90
[   31.085157]
---truncated---
CVE-2024-36008:In the Linux kernel, the following vulnerability has been resolved:
ipv4: check for NULL idev in ip_route_use_hint()
syzbot was able to trigger a NULL deref in fib_validate_source()
in an old tree [1].
It appears the bug exists in latest trees.
All calls to __in_dev_get_rcu() must be checked for a NULL result.
[1]
general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] SMP KASAN
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2~bpo12+1 04/01/2014
 RIP: 0010:fib_validate_source+0xbf/0x15a0 net/ipv4/fib_frontend.c:425
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
RSP: 0018:ffffc900015fee40 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0
RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0
RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000
R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000
R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000
FS:  00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
  ip_route_use_hint+0x410/0x9b0 net/ipv4/route.c:2231
  ip_rcv_finish_core+0x2c4/0x1a30 net/ipv4/ip_input.c:327
  ip_list_rcv_finish net/ipv4/ip_input.c:612 [inline]
  ip_sublist_rcv+0x3ed/0xe50 net/ipv4/ip_input.c:638
  ip_list_rcv+0x422/0x470 net/ipv4/ip_input.c:673
  __netif_receive_skb_list_ptype net/core/dev.c:5572 [inline]
  __netif_receive_skb_list_core+0x6b1/0x890 net/core/dev.c:5620
  __netif_receive_skb_list net/core/dev.c:5672 [inline]
  netif_receive_skb_list_internal+0x9f9/0xdc0 net/core/dev.c:5764
  netif_receive_skb_list+0x55/0x3e0 net/core/dev.c:5816
  xdp_recv_frames net/bpf/test_run.c:257 [inline]
  xdp_test_run_batch net/bpf/test_run.c:335 [inline]
  bpf_test_run_xdp_live+0x1818/0x1d00 net/bpf/test_run.c:363
  bpf_prog_test_run_xdp+0x81f/0x1170 net/bpf/test_run.c:1376
  bpf_prog_test_run+0x349/0x3c0 kernel/bpf/syscall.c:3736
  __sys_bpf+0x45c/0x710 kernel/bpf/syscall.c:5115
  __do_sys_bpf kernel/bpf/syscall.c:5201 [inline]
  __se_sys_bpf kernel/bpf/syscall.c:5199 [inline]
  __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5199
CVE-2024-36954:In the Linux kernel, the following vulnerability has been resolved:
tipc: fix a possible memleak in tipc_buf_append
__skb_linearize() doesn't free the skb when it fails, so move
'*buf = NULL' after __skb_linearize(), so that the skb can be
freed on the err path.
CVE-2021-47421:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resume
In current code, when a PCI error state pci_channel_io_normal is detectd,
it will report PCI_ERS_RESULT_CAN_RECOVER status to PCI driver, and PCI
driver will continue the execution of PCI resume callback report_resume by
pci_walk_bridge, and the callback will go into amdgpu_pci_resume
finally, where write lock is releasd unconditionally without acquiring
such lock first. In this case, a deadlock will happen when other threads
start to acquire the read lock.
To fix this, add a member in amdgpu_device strucutre to cache
pci_channel_state, and only continue the execution in amdgpu_pci_resume
when it's pci_channel_io_frozen.
CVE-2021-47455:In the Linux kernel, the following vulnerability has been resolved:
ptp: Fix possible memory leak in ptp_clock_register()
I got memory leak as follows when doing fault injection test:
unreferenced object 0xffff88800906c618 (size 8):
  comm &quot;i2c-idt82p33931&quot;, pid 4421, jiffies 4294948083 (age 13.188s)
  hex dump (first 8 bytes):
    70 74 70 30 00 00 00 00                          ptp0....
  backtrace:
    [&lt;00000000312ed458&gt;] __kmalloc_track_caller+0x19f/0x3a0
    [&lt;0000000079f6e2ff&gt;] kvasprintf+0xb5/0x150
    [&lt;0000000026aae54f&gt;] kvasprintf_const+0x60/0x190
    [&lt;00000000f323a5f7&gt;] kobject_set_name_vargs+0x56/0x150
    [&lt;000000004e35abdd&gt;] dev_set_name+0xc0/0x100
    [&lt;00000000f20cfe25&gt;] ptp_clock_register+0x9f4/0xd30 [ptp]
    [&lt;000000008bb9f0de&gt;] idt82p33_probe.cold+0x8b6/0x1561 [ptp_idt82p33]
When posix_clock_register() returns an error, the name allocated
in dev_set_name() will be leaked, the put_device() should be used
to give up the device reference, then the name will be freed in
kobject_cleanup() and other memory will be freed in ptp_clock_release().
CVE-2022-48659:In the Linux kernel, the following vulnerability has been resolved:
mm/slub: fix to return errno if kmalloc() fails
In create_unique_id(), kmalloc(, GFP_KERNEL) can fail due to
out-of-memory, if it fails, return errno correctly rather than
triggering panic via BUG_ON();
kernel BUG at mm/slub.c:5893!
Internal error: Oops - BUG: 0 [#1] PREEMPT SMP
Call trace:
 sysfs_slab_add+0x258/0x260 mm/slub.c:5973
 __kmem_cache_create+0x60/0x118 mm/slub.c:4899
 create_cache mm/slab_common.c:229 [inline]
 kmem_cache_create_usercopy+0x19c/0x31c mm/slab_common.c:335
 kmem_cache_create+0x1c/0x28 mm/slab_common.c:390
 f2fs_kmem_cache_create fs/f2fs/f2fs.h:2766 [inline]
 f2fs_init_xattr_caches+0x78/0xb4 fs/f2fs/xattr.c:808
 f2fs_fill_super+0x1050/0x1e0c fs/f2fs/super.c:4149
 mount_bdev+0x1b8/0x210 fs/super.c:1400
 f2fs_mount+0x44/0x58 fs/f2fs/super.c:4512
 legacy_get_tree+0x30/0x74 fs/fs_context.c:610
 vfs_get_tree+0x40/0x140 fs/super.c:1530
 do_new_mount+0x1dc/0x4e4 fs/namespace.c:3040
 path_mount+0x358/0x914 fs/namespace.c:3370
 do_mount fs/namespace.c:3383 [inline]
 __do_sys_mount fs/namespace.c:3591 [inline]
 __se_sys_mount fs/namespace.c:3568 [inline]
 __arm64_sys_mount+0x2f8/0x408 fs/namespace.c:3568
CVE-2022-48660:In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: Set lineevent_state::irq after IRQ register successfully
When running gpio test on nxp-ls1028 platform with below command
gpiomon --num-events=3 --rising-edge gpiochip1 25
There will be a warning trace as below:
Call trace:
free_irq+0x204/0x360
lineevent_free+0x64/0x70
gpio_ioctl+0x598/0x6a0
__arm64_sys_ioctl+0xb4/0x100
invoke_syscall+0x5c/0x130
......
el0t_64_sync+0x1a0/0x1a4
The reason of this issue is that calling request_threaded_irq()
function failed, and then lineevent_free() is invoked to release
the resource. Since the lineevent_state::irq was already set, so
the subsequent invocation of free_irq() would trigger the above
warning call trace. To fix this issue, set the lineevent_state::irq
after the IRQ register successfully.
CVE-2022-48708:In the Linux kernel, the following vulnerability has been resolved:
pinctrl: single: fix potential NULL dereference
Added checking of pointer &quot;function&quot; in pcs_set_mux().
pinmux_generic_get_function() can return NULL and the pointer
&quot;function&quot; was dereferenced without checking against NULL.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-52609:In the Linux kernel, the following vulnerability has been resolved:
binder: fix race between mmput() and do_exit()
Task A calls binder_update_page_range() to allocate and insert pages on
a remote address space from Task B. For this, Task A pins the remote mm
via mmget_not_zero() first. This can race with Task B do_exit() and the
final mmput() refcount decrement will come from Task A.
  Task A            | Task B
  ------------------+------------------
  mmget_not_zero()  |
                    |  do_exit()
                    |    exit_mm()
                    |      mmput()
  mmput()           |
    exit_mmap()     |
      remove_vma()  |
        fput()      |
In this case, the work of ____fput() from Task B is queued up in Task A
as TWA_RESUME. So in theory, Task A returns to userspace and the cleanup
work gets executed. However, Task A instead sleep, waiting for a reply
from Task B that never comes (it's dead).
This means the binder_deferred_release() is blocked until an unrelated
binder event forces Task A to go back to userspace. All the associated
death notifications will also be delayed until then.
In order to fix this use mmput_async() that will schedule the work in
the corresponding mm-&gt;async_put_work WQ instead of Task A.
CVE-2023-52615:In the Linux kernel, the following vulnerability has been resolved:
hwrng: core - Fix page fault dead lock on mmap-ed hwrng
There is a dead-lock in the hwrng device read path.  This triggers
when the user reads from /dev/hwrng into memory also mmap-ed from
/dev/hwrng.  The resulting page fault triggers a recursive read
which then dead-locks.
Fix this by using a stack buffer when calling copy_to_user.
CVE-2023-52616:In the Linux kernel, the following vulnerability has been resolved:
crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_init
When the mpi_ec_ctx structure is initialized, some fields are not
cleared, causing a crash when referencing the field when the
structure was released. Initially, this issue was ignored because
memory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.
For example, this error will be triggered when calculating the
Za value for SM2 separately.
CVE-2023-52618:In the Linux kernel, the following vulnerability has been resolved:
block/rnbd-srv: Check for unlikely string overflow
Since &quot;dev_search_path&quot; can technically be as large as PATH_MAX,
there was a risk of truncation when copying it and a second string
into &quot;full_path&quot; since it was also PATH_MAX sized. The W=1 builds were
reporting this warning:
drivers/block/rnbd/rnbd-srv.c: In function 'process_msg_open.isra':
drivers/block/rnbd/rnbd-srv.c:616:51: warning: '%s' directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]
  616 |                 snprintf(full_path, PATH_MAX, &quot;%s/%s&quot;,
      |                                                   ^~
In function 'rnbd_srv_get_full_path',
    inlined from 'process_msg_open.isra' at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: 'snprintf' output between 2 and 4351 bytes into a destination of size 4096
  616 |                 snprintf(full_path, PATH_MAX, &quot;%s/%s&quot;,
      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  617 |                          dev_search_path, dev_name);
      |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~
To fix this, unconditionally check for truncation (as was already done
for the case where &quot;%SESSNAME%&quot; was present).
CVE-2023-52621:In the Linux kernel, the following vulnerability has been resolved:
bpf: Check rcu_read_lock_trace_held() before calling bpf map helpers
These three bpf_map_{lookup,update,delete}_elem() helpers are also
available for sleepable bpf program, so add the corresponding lock
assertion for sleepable bpf program, otherwise the following warning
will be reported when a sleepable bpf program manipulates bpf map under
interpreter mode (aka bpf_jit_enable=0):
  WARNING: CPU: 3 PID: 4985 at kernel/bpf/helpers.c:40 ......
  CPU: 3 PID: 4985 Comm: test_progs Not tainted 6.6.0+ #2
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996) ......
  RIP: 0010:bpf_map_lookup_elem+0x54/0x60
  ......
  Call Trace:
   &lt;TASK&gt;
   ? __warn+0xa5/0x240
   ? bpf_map_lookup_elem+0x54/0x60
   ? report_bug+0x1ba/0x1f0
   ? handle_bug+0x40/0x80
   ? exc_invalid_op+0x18/0x50
   ? asm_exc_invalid_op+0x1b/0x20
   ? __pfx_bpf_map_lookup_elem+0x10/0x10
   ? rcu_lockdep_current_cpu_online+0x65/0xb0
   ? rcu_is_watching+0x23/0x50
   ? bpf_map_lookup_elem+0x54/0x60
   ? __pfx_bpf_map_lookup_elem+0x10/0x10
   ___bpf_prog_run+0x513/0x3b70
   __bpf_prog_run32+0x9d/0xd0
   ? __bpf_prog_enter_sleepable_recur+0xad/0x120
   ? __bpf_prog_enter_sleepable_recur+0x3e/0x120
   bpf_trampoline_6442580665+0x4d/0x1000
   __x64_sys_getpgid+0x5/0x30
   ? do_syscall_64+0x36/0xb0
   entry_SYSCALL_64_after_hwframe+0x6e/0x76
   &lt;/TASK&gt;
CVE-2023-52623:In the Linux kernel, the following vulnerability has been resolved:
SUNRPC: Fix a suspicious RCU usage warning
I received the following warning while running cthon against an ontap
server running pNFS:
[   57.202521] =============================
[   57.202522] WARNING: suspicious RCU usage
[   57.202523] 6.7.0-rc3-g2cc14f52aeb7 #41492 Not tainted
[   57.202525] -----------------------------
[   57.202525] net/sunrpc/xprtmultipath.c:349 RCU-list traversed in non-reader section!!
[   57.202527]
               other info that might help us debug this:
[   57.202528]
               rcu_scheduler_active = 2, debug_locks = 1
[   57.202529] no locks held by test5/3567.
[   57.202530]
               stack backtrace:
[   57.202532] CPU: 0 PID: 3567 Comm: test5 Not tainted 6.7.0-rc3-g2cc14f52aeb7 #41492 5b09971b4965c0aceba19f3eea324a4a806e227e
[   57.202534] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS unknown 2/2/2022
[   57.202536] Call Trace:
[   57.202537]  &lt;TASK&gt;
[   57.202540]  dump_stack_lvl+0x77/0xb0
[   57.202551]  lockdep_rcu_suspicious+0x154/0x1a0
[   57.202556]  rpc_xprt_switch_has_addr+0x17c/0x190 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202596]  rpc_clnt_setup_test_and_add_xprt+0x50/0x180 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202621]  ? rpc_clnt_add_xprt+0x254/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202646]  rpc_clnt_add_xprt+0x27a/0x300 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202671]  ? __pfx_rpc_clnt_setup_test_and_add_xprt+0x10/0x10 [sunrpc ebe02571b9a8ceebf7d98e71675af20c19bdb1f6]
[   57.202696]  nfs4_pnfs_ds_connect+0x345/0x760 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[   57.202728]  ? __pfx_nfs4_test_session_trunk+0x10/0x10 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[   57.202754]  nfs4_fl_prepare_ds+0x75/0xc0 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
[   57.202760]  filelayout_write_pagelist+0x4a/0x200 [nfs_layout_nfsv41_files e3a4187f18ae8a27b630f9feae6831b584a9360a]
[   57.202765]  pnfs_generic_pg_writepages+0xbe/0x230 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[   57.202788]  __nfs_pageio_add_request+0x3fd/0x520 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202813]  nfs_pageio_add_request+0x18b/0x390 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202831]  nfs_do_writepage+0x116/0x1e0 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202849]  nfs_writepages_callback+0x13/0x30 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202866]  write_cache_pages+0x265/0x450
[   57.202870]  ? __pfx_nfs_writepages_callback+0x10/0x10 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202891]  nfs_writepages+0x141/0x230 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202913]  do_writepages+0xd2/0x230
[   57.202917]  ? filemap_fdatawrite_wbc+0x5c/0x80
[   57.202921]  filemap_fdatawrite_wbc+0x67/0x80
[   57.202924]  filemap_write_and_wait_range+0xd9/0x170
[   57.202930]  nfs_wb_all+0x49/0x180 [nfs 6c976fa593a7c2976f5a0aeb4965514a828e6902]
[   57.202947]  nfs4_file_flush+0x72/0xb0 [nfsv4 c716d88496ded0ea6d289bbea684fa996f9b57a9]
[   57.202969]  __se_sys_close+0x46/0xd0
[   57.202972]  do_syscall_64+0x68/0x100
[   57.202975]  ? do_syscall_64+0x77/0x100
[   57.202976]  ? do_syscall_64+0x77/0x100
[   57.202979]  entry_SYSCALL_64_after_hwframe+0x6e/0x76
[   57.202982] RIP: 0033:0x7fe2b12e4a94
[   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
[   57.202987] RSP: 002b:00007ffe857ddb38 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
[   57.202989] RAX: ffffffffffffffda RBX: 00007ffe857dfd68 RCX: 00007fe2b12e4a94
[   57.202991] RDX: 0000000000002000 RSI: 00007ffe857ddc40 RDI: 0000000000000003
[   57.202992] RBP: 00007ffe857dfc50 R08: 7fffffffffffffff R09: 0000000065650f49
[   57.202993] R10: 00007f
---truncated---
CVE-2023-52629:In the Linux kernel, the following vulnerability has been resolved:
sh: push-switch: Reorder cleanup operations to avoid use-after-free bug
The original code puts flush_work() before timer_shutdown_sync()
in switch_drv_remove(). Although we use flush_work() to stop
the worker, it could be rescheduled in switch_timer(). As a result,
a use-after-free bug can occur. The details are shown below:
      (cpu 0)                    |      (cpu 1)
switch_drv_remove()              |
 flush_work()                    |
  ...                            |  switch_timer // timer
                                 |   schedule_work(&amp;psw-&gt;work)
 timer_shutdown_sync()           |
 ...                             |  switch_work_handler // worker
 kfree(psw) // free              |
                                 |   psw-&gt;state = 0 // use
This patch puts timer_shutdown_sync() before flush_work() to
mitigate the bugs. As a result, the worker and timer will be
stopped safely before the deallocate operations.
CVE-2023-52630:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2023-52633:In the Linux kernel, the following vulnerability has been resolved:
um: time-travel: fix time corruption
In 'basic' time-travel mode (without =inf-cpu or =ext), we
still get timer interrupts. These can happen at arbitrary
points in time, i.e. while in timer_read(), which pushes
time forward just a little bit. Then, if we happen to get
the interrupt after calculating the new time to push to,
but before actually finishing that, the interrupt will set
the time to a value that's incompatible with the forward,
and we'll crash because time goes backwards when we do the
forwarding.
Fix this by reading the time_travel_time, calculating the
adjustment, and doing the adjustment all with interrupts
disabled.
CVE-2023-52635:In the Linux kernel, the following vulnerability has been resolved:
PM / devfreq: Synchronize devfreq_monitor_[start/stop]
There is a chance if a frequent switch of the governor
done in a loop result in timer list corruption where
timer cancel being done from two place one from
cancel_delayed_work_sync() and followed by expire_timers()
can be seen from the traces[1].
while true
do
        echo &quot;simple_ondemand&quot; &gt; /sys/class/devfreq/1d84000.ufshc/governor
        echo &quot;performance&quot; &gt; /sys/class/devfreq/1d84000.ufshc/governor
done
It looks to be issue with devfreq driver where
device_monitor_[start/stop] need to synchronized so that
delayed work should get corrupted while it is either
being queued or running or being cancelled.
Let's use polling flag and devfreq lock to synchronize the
queueing the timer instance twice and work data being
corrupted.
[1]
...
..
&lt;idle&gt;-0    [003]   9436.209662:  timer_cancel   timer=0xffffff80444f0428
&lt;idle&gt;-0    [003]   9436.209664:  timer_expire_entry   timer=0xffffff80444f0428  now=0x10022da1c  function=__typeid__ZTSFvP10timer_listE_global_addr  baseclk=0x10022da1c
&lt;idle&gt;-0    [003]   9436.209718:  timer_expire_exit   timer=0xffffff80444f0428
kworker/u16:6-14217    [003]   9436.209863:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2b  now=0x10022da1c  flags=182452227
vendor.xxxyyy.ha-1593    [004]   9436.209888:  timer_cancel   timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593    [004]   9436.216390:  timer_init   timer=0xffffff80444f0428
vendor.xxxyyy.ha-1593    [004]   9436.216392:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2c  now=0x10022da1d  flags=186646532
vendor.xxxyyy.ha-1593    [005]   9436.220992:  timer_cancel   timer=0xffffff80444f0428
xxxyyyTraceManag-7795    [004]   9436.261641:  timer_cancel   timer=0xffffff80444f0428
[2]
 9436.261653][    C4] Unable to handle kernel paging request at virtual address dead00000000012a
[ 9436.261664][    C4] Mem abort info:
[ 9436.261666][    C4]   ESR = 0x96000044
[ 9436.261669][    C4]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 9436.261671][    C4]   SET = 0, FnV = 0
[ 9436.261673][    C4]   EA = 0, S1PTW = 0
[ 9436.261675][    C4] Data abort info:
[ 9436.261677][    C4]   ISV = 0, ISS = 0x00000044
[ 9436.261680][    C4]   CM = 0, WnR = 1
[ 9436.261682][    C4] [dead00000000012a] address between user and kernel address ranges
[ 9436.261685][    C4] Internal error: Oops: 96000044 [#1] PREEMPT SMP
[ 9436.261701][    C4] Skip md ftrace buffer dump for: 0x3a982d0
...
[ 9436.262138][    C4] CPU: 4 PID: 7795 Comm: TraceManag Tainted: G S      W  O      5.10.149-android12-9-o-g17f915d29d0c #1
[ 9436.262141][    C4] Hardware name: Qualcomm Technologies, Inc.  (DT)
[ 9436.262144][    C4] pstate: 22400085 (nzCv daIf +PAN -UAO +TCO BTYPE=--)
[ 9436.262161][    C4] pc : expire_timers+0x9c/0x438
[ 9436.262164][    C4] lr : expire_timers+0x2a4/0x438
[ 9436.262168][    C4] sp : ffffffc010023dd0
[ 9436.262171][    C4] x29: ffffffc010023df0 x28: ffffffd0636fdc18
[ 9436.262178][    C4] x27: ffffffd063569dd0 x26: ffffffd063536008
[ 9436.262182][    C4] x25: 0000000000000001 x24: ffffff88f7c69280
[ 9436.262185][    C4] x23: 00000000000000e0 x22: dead000000000122
[ 9436.262188][    C4] x21: 000000010022da29 x20: ffffff8af72b4e80
[ 9436.262191][    C4] x19: ffffffc010023e50 x18: ffffffc010025038
[ 9436.262195][    C4] x17: 0000000000000240 x16: 0000000000000201
[ 9436.262199][    C4] x15: ffffffffffffffff x14: ffffff889f3c3100
[ 9436.262203][    C4] x13: ffffff889f3c3100 x12: 00000000049f56b8
[ 9436.262207][    C4] x11: 00000000049f56b8 x10: 00000000ffffffff
[ 9436.262212][    C4] x9 : ffffffc010023e50 x8 : dead000000000122
[ 9436.262216][    C4] x7 : ffffffffffffffff x6 : ffffffc0100239d8
[ 9436.262220][    C4] x5 : 0000000000000000 x4 : 0000000000000101
[ 9436.262223][    C4] x3 : 0000000000000080 x2 : ffffff8
---truncated---
CVE-2023-52637:In the Linux kernel, the following vulnerability has been resolved:
can: j1939: Fix UAF in j1939_sk_match_filter during setsockopt(SO_J1939_FILTER)
Lock jsk-&gt;sk to prevent UAF when setsockopt(..., SO_J1939_FILTER, ...)
modifies jsk-&gt;filters while receiving packets.
Following trace was seen on affected system:
 ==================================================================
 BUG: KASAN: slab-use-after-free in j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
 Read of size 4 at addr ffff888012144014 by task j1939/350
 CPU: 0 PID: 350 Comm: j1939 Tainted: G        W  OE      6.5.0-rc5 #1
 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014
 Call Trace:
  print_report+0xd3/0x620
  ? kasan_complete_mode_report_info+0x7d/0x200
  ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
  kasan_report+0xc2/0x100
  ? j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
  __asan_load4+0x84/0xb0
  j1939_sk_recv_match_one+0x1af/0x2d0 [can_j1939]
  j1939_sk_recv+0x20b/0x320 [can_j1939]
  ? __kasan_check_write+0x18/0x20
  ? __pfx_j1939_sk_recv+0x10/0x10 [can_j1939]
  ? j1939_simple_recv+0x69/0x280 [can_j1939]
  ? j1939_ac_recv+0x5e/0x310 [can_j1939]
  j1939_can_recv+0x43f/0x580 [can_j1939]
  ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
  ? raw_rcv+0x42/0x3c0 [can_raw]
  ? __pfx_j1939_can_recv+0x10/0x10 [can_j1939]
  can_rcv_filter+0x11f/0x350 [can]
  can_receive+0x12f/0x190 [can]
  ? __pfx_can_rcv+0x10/0x10 [can]
  can_rcv+0xdd/0x130 [can]
  ? __pfx_can_rcv+0x10/0x10 [can]
  __netif_receive_skb_one_core+0x13d/0x150
  ? __pfx___netif_receive_skb_one_core+0x10/0x10
  ? __kasan_check_write+0x18/0x20
  ? _raw_spin_lock_irq+0x8c/0xe0
  __netif_receive_skb+0x23/0xb0
  process_backlog+0x107/0x260
  __napi_poll+0x69/0x310
  net_rx_action+0x2a1/0x580
  ? __pfx_net_rx_action+0x10/0x10
  ? __pfx__raw_spin_lock+0x10/0x10
  ? handle_irq_event+0x7d/0xa0
  __do_softirq+0xf3/0x3f8
  do_softirq+0x53/0x80
  &lt;/IRQ&gt;
  &lt;TASK&gt;
  __local_bh_enable_ip+0x6e/0x70
  netif_rx+0x16b/0x180
  can_send+0x32b/0x520 [can]
  ? __pfx_can_send+0x10/0x10 [can]
  ? __check_object_size+0x299/0x410
  raw_sendmsg+0x572/0x6d0 [can_raw]
  ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
  ? apparmor_socket_sendmsg+0x2f/0x40
  ? __pfx_raw_sendmsg+0x10/0x10 [can_raw]
  sock_sendmsg+0xef/0x100
  sock_write_iter+0x162/0x220
  ? __pfx_sock_write_iter+0x10/0x10
  ? __rtnl_unlock+0x47/0x80
  ? security_file_permission+0x54/0x320
  vfs_write+0x6ba/0x750
  ? __pfx_vfs_write+0x10/0x10
  ? __fget_light+0x1ca/0x1f0
  ? __rcu_read_unlock+0x5b/0x280
  ksys_write+0x143/0x170
  ? __pfx_ksys_write+0x10/0x10
  ? __kasan_check_read+0x15/0x20
  ? fpregs_assert_state_consistent+0x62/0x70
  __x64_sys_write+0x47/0x60
  do_syscall_64+0x60/0x90
  ? do_syscall_64+0x6d/0x90
  ? irqentry_exit+0x3f/0x50
  ? exc_page_fault+0x79/0xf0
  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
 Allocated by task 348:
  kasan_save_stack+0x2a/0x50
  kasan_set_track+0x29/0x40
  kasan_save_alloc_info+0x1f/0x30
  __kasan_kmalloc+0xb5/0xc0
  __kmalloc_node_track_caller+0x67/0x160
  j1939_sk_setsockopt+0x284/0x450 [can_j1939]
  __sys_setsockopt+0x15c/0x2f0
  __x64_sys_setsockopt+0x6b/0x80
  do_syscall_64+0x60/0x90
  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
 Freed by task 349:
  kasan_save_stack+0x2a/0x50
  kasan_set_track+0x29/0x40
  kasan_save_free_info+0x2f/0x50
  __kasan_slab_free+0x12e/0x1c0
  __kmem_cache_free+0x1b9/0x380
  kfree+0x7a/0x120
  j1939_sk_setsockopt+0x3b2/0x450 [can_j1939]
  __sys_setsockopt+0x15c/0x2f0
  __x64_sys_setsockopt+0x6b/0x80
  do_syscall_64+0x60/0x90
  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
CVE-2023-52639:In the Linux kernel, the following vulnerability has been resolved:
KVM: s390: vsie: fix race during shadow creation
Right now it is possible to see gmap-&gt;private being zero in
kvm_s390_vsie_gmap_notifier resulting in a crash.  This is due to the
fact that we add gmap-&gt;private == kvm after creation:
static int acquire_gmap_shadow(struct kvm_vcpu *vcpu,
                               struct vsie_page *vsie_page)
{
[...]
        gmap = gmap_shadow(vcpu-&gt;arch.gmap, asce, edat);
        if (IS_ERR(gmap))
                return PTR_ERR(gmap);
        gmap-&gt;private = vcpu-&gt;kvm;
Let children inherit the private field of the parent.
CVE-2023-52644:In the Linux kernel, the following vulnerability has been resolved:
wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabled
When QoS is disabled, the queue priority value will not map to the correct
ieee80211 queue since there is only one queue. Stop/wake queue 0 when QoS
is disabled to prevent trying to stop/wake a non-existent queue and failing
to stop/wake the actual queue instantiated.
Log of issue before change (with kernel parameter qos=0):
    [  +5.112651] ------------[ cut here ]------------
    [  +0.000005] WARNING: CPU: 7 PID: 25513 at net/mac80211/util.c:449 __ieee80211_wake_queue+0xd5/0x180 [mac80211]
    [  +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
    [  +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
    [  +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)]
    [  +0.000009] CPU: 7 PID: 25513 Comm: irq/17-b43 Tainted: G        W  O       6.6.7 #1-NixOS
    [  +0.000003] Hardware name: Apple Inc. MacBookPro8,3/Mac-942459F5819B171B, BIOS 87.0.0.0.0 06/13/2019
    [  +0.000001] RIP: 0010:__ieee80211_wake_queue+0xd5/0x180 [mac80211]
    [  +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
    [  +0.000002] RSP: 0018:ffffc90003c77d60 EFLAGS: 00010097
    [  +0.000001] RAX: 0000000000000001 RBX: 0000000000000002 RCX: 0000000000000000
    [  +0.000001] RDX: 0000000000000000 RSI: 0000000000000002 RDI: ffff88820b924900
    [  +0.000002] RBP: ffff88820b924900 R08: ffffc90003c77d90 R09: 000000000003bfd0
    [  +0.000001] R10: ffff88820b924900 R11: ffffc90003c77c68 R12: 0000000000000000
    [  +0.000001] R13: 0000000000000000 R14: ffffc90003c77d90 R15: ffffffffc0fa6f40
    [  +0.000001] FS:  0000000000000000(0000) GS:ffff88846fb80000(0000) knlGS:0000000000000000
    [  +0.000001] CS:  0010 DS: 0
---truncated---
CVE-2023-52656:In the Linux kernel, the following vulnerability has been resolved:
io_uring: drop any code related to SCM_RIGHTS
This is dead code after we dropped support for passing io_uring fds
over SCM_RIGHTS, get rid of it.
CVE-2023-52664:In the Linux kernel, the following vulnerability has been resolved:
net: atlantic: eliminate double free in error handling logic
Driver has a logic leak in ring data allocation/free,
where aq_ring_free could be called multiple times on same ring,
if system is under stress and got memory allocation error.
Ring pointer was used as an indicator of failure, but this is
not correct since only ring data is allocated/deallocated.
Ring itself is an array member.
Changing ring allocation functions to return error code directly.
This simplifies error handling and eliminates aq_ring_free
on higher layer.
CVE-2023-52675:In the Linux kernel, the following vulnerability has been resolved:
powerpc/imc-pmu: Add a null pointer check in update_events_in_group()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
CVE-2023-52676:In the Linux kernel, the following vulnerability has been resolved:
bpf: Guard stack limits against 32bit overflow
This patch promotes the arithmetic around checking stack bounds to be
done in the 64-bit domain, instead of the current 32bit. The arithmetic
implies adding together a 64-bit register with a int offset. The
register was checked to be below 1&lt;&lt;29 when it was variable, but not
when it was fixed. The offset either comes from an instruction (in which
case it is 16 bit), from another register (in which case the caller
checked it to be below 1&lt;&lt;29 [1]), or from the size of an argument to a
kfunc (in which case it can be a u32 [2]). Between the register being
inconsistently checked to be below 1&lt;&lt;29, and the offset being up to an
u32, it appears that we were open to overflowing the `int`s which were
currently used for arithmetic.
[1] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L7494-L7498
[2] https://github.com/torvalds/linux/blob/815fb87b753055df2d9e50f6cd80eb10235fe3e9/kernel/bpf/verifier.c#L11904
CVE-2023-52683:In the Linux kernel, the following vulnerability has been resolved:
ACPI: LPIT: Avoid u32 multiplication overflow
In lpit_update_residency() there is a possibility of overflow
in multiplication, if tsc_khz is large enough (&gt; UINT_MAX/1000).
Change multiplication to mul_u32_u32().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2023-52685:In the Linux kernel, the following vulnerability has been resolved:
pstore: ram_core: fix possible overflow in persistent_ram_init_ecc()
In persistent_ram_init_ecc(), on 64-bit arches DIV_ROUND_UP() will return
64-bit value since persistent_ram_zone::buffer_size has type size_t which
is derived from the 64-bit *unsigned long*, while the ecc_blocks variable
this value gets assigned to has (always 32-bit) *int* type.  Even if that
value fits into *int* type, an overflow is still possible when calculating
the size_t typed ecc_total variable further below since there's no cast to
any 64-bit type before multiplication.  Declaring the ecc_blocks variable
as *size_t* should fix this mess...
Found by Linux Verification Center (linuxtesting.org) with the SVACE static
analysis tool.
CVE-2023-52690:In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check to scom_debug_init_one()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
Add a null pointer check, and release 'ent' to avoid memory leaks.
CVE-2023-52694:In the Linux kernel, the following vulnerability has been resolved:
drm/bridge: tpd12s015: Drop buggy __exit annotation for remove function
With tpd12s015_remove() marked with __exit this function is discarded
when the driver is compiled as a built-in. The result is that when the
driver unbinds there is no cleanup done which results in resource
leakage or worse.
CVE-2023-52698:In the Linux kernel, the following vulnerability has been resolved:
calipso: fix memory leak in netlbl_calipso_add_pass()
If IPv6 support is disabled at boot (ipv6.disable=1),
the calipso_init() -&gt; netlbl_calipso_ops_register() function isn't called,
and the netlbl_calipso_ops_get() function always returns NULL.
In this case, the netlbl_calipso_add_pass() function allocates memory
for the doi_def variable but doesn't free it with the calipso_doi_free().
BUG: memory leak
unreferenced object 0xffff888011d68180 (size 64):
  comm &quot;syz-executor.1&quot;, pid 10746, jiffies 4295410986 (age 17.928s)
  hex dump (first 32 bytes):
    00 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;...&gt;] kmalloc include/linux/slab.h:552 [inline]
    [&lt;...&gt;] netlbl_calipso_add_pass net/netlabel/netlabel_calipso.c:76 [inline]
    [&lt;...&gt;] netlbl_calipso_add+0x22e/0x4f0 net/netlabel/netlabel_calipso.c:111
    [&lt;...&gt;] genl_family_rcv_msg_doit+0x22f/0x330 net/netlink/genetlink.c:739
    [&lt;...&gt;] genl_family_rcv_msg net/netlink/genetlink.c:783 [inline]
    [&lt;...&gt;] genl_rcv_msg+0x341/0x5a0 net/netlink/genetlink.c:800
    [&lt;...&gt;] netlink_rcv_skb+0x14d/0x440 net/netlink/af_netlink.c:2515
    [&lt;...&gt;] genl_rcv+0x29/0x40 net/netlink/genetlink.c:811
    [&lt;...&gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1313 [inline]
    [&lt;...&gt;] netlink_unicast+0x54b/0x800 net/netlink/af_netlink.c:1339
    [&lt;...&gt;] netlink_sendmsg+0x90a/0xdf0 net/netlink/af_netlink.c:1934
    [&lt;...&gt;] sock_sendmsg_nosec net/socket.c:651 [inline]
    [&lt;...&gt;] sock_sendmsg+0x157/0x190 net/socket.c:671
    [&lt;...&gt;] ____sys_sendmsg+0x712/0x870 net/socket.c:2342
    [&lt;...&gt;] ___sys_sendmsg+0xf8/0x170 net/socket.c:2396
    [&lt;...&gt;] __sys_sendmsg+0xea/0x1b0 net/socket.c:2429
    [&lt;...&gt;] do_syscall_64+0x30/0x40 arch/x86/entry/common.c:46
    [&lt;...&gt;] entry_SYSCALL_64_after_hwframe+0x61/0xc6
Found by InfoTeCS on behalf of Linux Verification Center
(linuxtesting.org) with Syzkaller
[PM: merged via the LSM tree at Jakub Kicinski request]
CVE-2023-52809:In the Linux kernel, the following vulnerability has been resolved:
scsi: libfc: Fix potential NULL pointer dereference in fc_lport_ptp_setup()
fc_lport_ptp_setup() did not check the return value of fc_rport_create()
which can return NULL and would cause a NULL pointer dereference. Address
this issue by checking return value of fc_rport_create() and log error
message on fc_rport_create() failed.
CVE-2023-52835:In the Linux kernel, the following vulnerability has been resolved:
perf/core: Bail out early if the request AUX area is out of bound
When perf-record with a large AUX area, e.g 4GB, it fails with:
    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
    failed to mmap with 12 (Cannot allocate memory)
and it reveals a WARNING with __alloc_pages():
	------------[ cut here ]------------
	WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248
	Call trace:
	 __alloc_pages+0x1ec/0x248
	 __kmalloc_large_node+0xc0/0x1f8
	 __kmalloc_node+0x134/0x1e8
	 rb_alloc_aux+0xe0/0x298
	 perf_mmap+0x440/0x660
	 mmap_region+0x308/0x8a8
	 do_mmap+0x3c0/0x528
	 vm_mmap_pgoff+0xf4/0x1b8
	 ksys_mmap_pgoff+0x18c/0x218
	 __arm64_sys_mmap+0x38/0x58
	 invoke_syscall+0x50/0x128
	 el0_svc_common.constprop.0+0x58/0x188
	 do_el0_svc+0x34/0x50
	 el0_svc+0x34/0x108
	 el0t_64_sync_handler+0xb8/0xc0
	 el0t_64_sync+0x1a4/0x1a8
'rb-&gt;aux_pages' allocated by kcalloc() is a pointer array which is used to
maintains AUX trace pages. The allocated page for this array is physically
contiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If the
size of pointer array crosses the limitation set by MAX_ORDER, it reveals a
WARNING.
So bail out early with -ENOMEM if the request AUX area is out of bound,
e.g.:
    #perf record -C 0 -m ,4G -e arm_spe_0// -- sleep 1
    failed to mmap with 12 (Cannot allocate memory)
CVE-2023-52840:In the Linux kernel, the following vulnerability has been resolved:
Input: synaptics-rmi4 - fix use after free in rmi_unregister_function()
The put_device() calls rmi_release_function() which frees &quot;fn&quot; so the
dereference on the next line &quot;fn-&gt;num_of_irqs&quot; is a use after free.
Move the put_device() to the end to fix this.
CVE-2023-52841:In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: mux: Add check and kfree for kstrdup
Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.
Moreover, use kfree() in the later error handling in order to avoid
memory leak.
CVE-2023-52844:In the Linux kernel, the following vulnerability has been resolved:
media: vidtv: psi: Add check for kstrdup
Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.
CVE-2023-52847:In the Linux kernel, the following vulnerability has been resolved:
media: bttv: fix use after free error due to btv-&gt;timeout timer
There may be some a race condition between timer function
bttv_irq_timeout and bttv_remove. The timer is setup in
probe and there is no timer_delete operation in remove
function. When it hit kfree btv, the function might still be
invoked, which will cause use after free bug.
This bug is found by static analysis, it may be false positive.
Fix it by adding del_timer_sync invoking to the remove function.
cpu0                cpu1
                  bttv_probe
                    -&gt;timer_setup
                      -&gt;bttv_set_dma
                        -&gt;mod_timer;
bttv_remove
  -&gt;kfree(btv);
                  -&gt;bttv_irq_timeout
                    -&gt;USE btv
CVE-2023-52854:In the Linux kernel, the following vulnerability has been resolved:
padata: Fix refcnt handling in padata_free_shell()
In a high-load arm64 environment, the pcrypt_aead01 test in LTP can lead
to system UAF (Use-After-Free) issues. Due to the lengthy analysis of
the pcrypt_aead01 function call, I'll describe the problem scenario
using a simplified model:
Suppose there's a user of padata named `user_function` that adheres to
the padata requirement of calling `padata_free_shell` after `serial()`
has been invoked, as demonstrated in the following code:
```c
struct request {
    struct padata_priv padata;
    struct completion *done;
};
void parallel(struct padata_priv *padata) {
    do_something();
}
void serial(struct padata_priv *padata) {
    struct request *request = container_of(padata,
    				struct request,
				padata);
    complete(request-&gt;done);
}
void user_function() {
    DECLARE_COMPLETION(done)
    padata-&gt;parallel = parallel;
    padata-&gt;serial = serial;
    padata_do_parallel();
    wait_for_completion(&amp;done);
    padata_free_shell();
}
```
In the corresponding padata.c file, there's the following code:
```c
static void padata_serial_worker(struct work_struct *serial_work) {
    ...
    cnt = 0;
    while (!list_empty(&amp;local_list)) {
        ...
        padata-&gt;serial(padata);
        cnt++;
    }
    local_bh_enable();
    if (refcount_sub_and_test(cnt, &amp;pd-&gt;refcnt))
        padata_free_pd(pd);
}
```
Because of the high system load and the accumulation of unexecuted
softirq at this moment, `local_bh_enable()` in padata takes longer
to execute than usual. Subsequently, when accessing `pd-&gt;refcnt`,
`pd` has already been released by `padata_free_shell()`, resulting
in a UAF issue with `pd-&gt;refcnt`.
The fix is straightforward: add `refcount_dec_and_test` before calling
`padata_free_pd` in `padata_free_shell`.
CVE-2023-52860:In the Linux kernel, the following vulnerability has been resolved:
drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit process
When tearing down a 'hisi_hns3' PMU, we mistakenly run the CPU hotplug
callbacks after the device has been unregistered, leading to fireworks
when we try to execute empty function callbacks within the driver:
  | Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
  | CPU: 0 PID: 15 Comm: cpuhp/0 Tainted: G        W  O      5.12.0-rc4+ #1
  | Hardware name:  , BIOS KpxxxFPGA 1P B600 V143 04/22/2021
  | pstate: 80400009 (Nzcv daif +PAN -UAO -TCO BTYPE=--)
  | pc : perf_pmu_migrate_context+0x98/0x38c
  | lr : perf_pmu_migrate_context+0x94/0x38c
  |
  | Call trace:
  |  perf_pmu_migrate_context+0x98/0x38c
  |  hisi_hns3_pmu_offline_cpu+0x104/0x12c [hisi_hns3_pmu]
Use cpuhp_state_remove_instance_nocalls() instead of
cpuhp_state_remove_instance() so that the notifiers don't execute after
the PMU device has been unregistered.
[will: Rewrote commit message]
CVE-2023-52863:In the Linux kernel, the following vulnerability has been resolved:
hwmon: (axi-fan-control) Fix possible NULL pointer dereference
axi_fan_control_irq_handler(), dependent on the private
axi_fan_control_data structure, might be called before the hwmon
device is registered. That will cause an &quot;Unable to handle kernel
NULL pointer dereference&quot; error.
CVE-2023-52869:In the Linux kernel, the following vulnerability has been resolved:
pstore/platform: Add check for kstrdup
Add check for the return value of kstrdup() and return the error
if it fails in order to avoid NULL pointer dereference.
CVE-2023-52870:In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: clk-mt6765: Add check for mtk_alloc_clk_data
Add the check for the return value of mtk_alloc_clk_data() in order to
avoid NULL pointer dereference.
CVE-2024-24860:A race condition was found in the Linux kernel'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.
CVE-2024-26610:In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: fix a memory corruption
iwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means that
if we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is in
bytes, we'll write past the buffer.
CVE-2024-26633:In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: fix NEXTHDR_FRAGMENT handling in ip6_tnl_parse_tlv_enc_lim()
syzbot pointed out [1] that NEXTHDR_FRAGMENT handling is broken.
Reading frag_off can only be done if we pulled enough bytes
to skb-&gt;head. Currently we might access garbage.
[1]
BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
dst_output include/net/dst.h:451 [inline]
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendmsg net/socket.c:2676 [inline]
__se_sys_sendmsg net/socket.c:2674 [inline]
__x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
do_syscall_x64 arch/x86/entry/common.c:52 [inline]
do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
slab_alloc_node mm/slub.c:3478 [inline]
__kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
__do_kmalloc_node mm/slab_common.c:1006 [inline]
__kmalloc_node_track_caller+0x118/0x3c0 mm/slab_common.c:1027
kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098
__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655
pskb_may_pull_reason include/linux/skbuff.h:2673 [inline]
pskb_may_pull include/linux/skbuff.h:2681 [inline]
ip6_tnl_parse_tlv_enc_lim+0x901/0xbb0 net/ipv6/ip6_tunnel.c:408
ipxip6_tnl_xmit net/ipv6/ip6_tunnel.c:1326 [inline]
ip6_tnl_start_xmit+0xab2/0x1a70 net/ipv6/ip6_tunnel.c:1432
__netdev_start_xmit include/linux/netdevice.h:4940 [inline]
netdev_start_xmit include/linux/netdevice.h:4954 [inline]
xmit_one net/core/dev.c:3548 [inline]
dev_hard_start_xmit+0x247/0xa10 net/core/dev.c:3564
__dev_queue_xmit+0x33b8/0x5130 net/core/dev.c:4349
dev_queue_xmit include/linux/netdevice.h:3134 [inline]
neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592
neigh_output include/net/neighbour.h:542 [inline]
ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137
ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222
NF_HOOK_COND include/linux/netfilter.h:303 [inline]
ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243
dst_output include/net/dst.h:451 [inline]
ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155
ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]
ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972
rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582
rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920
inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847
sock_sendmsg_nosec net/socket.c:730 [inline]
__sock_sendmsg net/socket.c:745 [inline]
____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
__sys_sendmsg net/socket.c:2667 [inline]
__do_sys_sendms
---truncated---
CVE-2024-26635:In the Linux kernel, the following vulnerability has been resolved:
llc: Drop support for ETH_P_TR_802_2.
syzbot reported an uninit-value bug below. [0]
llc supports ETH_P_802_2 (0x0004) and used to support ETH_P_TR_802_2
(0x0011), and syzbot abused the latter to trigger the bug.
  write$tun(r0, &amp;(0x7f0000000040)={@val={0x0, 0x11}, @val, @mpls={[], @llc={@snap={0xaa, 0x1, ')', &quot;90e5dd&quot;}}}}, 0x16)
llc_conn_handler() initialises local variables {saddr,daddr}.mac
based on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passes
them to __llc_lookup().
However, the initialisation is done only when skb-&gt;protocol is
htons(ETH_P_802_2), otherwise, __llc_lookup_established() and
__llc_lookup_listener() will read garbage.
The missing initialisation existed prior to commit 211ed865108e
(&quot;net: delete all instances of special processing for token ring&quot;).
It removed the part to kick out the token ring stuff but forgot to
close the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().
Let's remove llc_tr_packet_type and complete the deprecation.
[0]:
BUG: KMSAN: uninit-value in __llc_lookup_established+0xe9d/0xf90
 __llc_lookup_established+0xe9d/0xf90
 __llc_lookup net/llc/llc_conn.c:611 [inline]
 llc_conn_handler+0x4bd/0x1360 net/llc/llc_conn.c:791
 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
 __netif_receive_skb_one_core net/core/dev.c:5527 [inline]
 __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5641
 netif_receive_skb_internal net/core/dev.c:5727 [inline]
 netif_receive_skb+0x58/0x660 net/core/dev.c:5786
 tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
 tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
 tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
 call_write_iter include/linux/fs.h:2020 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x8ef/0x1490 fs/read_write.c:584
 ksys_write+0x20f/0x4c0 fs/read_write.c:637
 __do_sys_write fs/read_write.c:649 [inline]
 __se_sys_write fs/read_write.c:646 [inline]
 __x64_sys_write+0x93/0xd0 fs/read_write.c:646
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x44/0x110 arch/x86/entry/common.c:82
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Local variable daddr created at:
 llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783
 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206
CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
CVE-2024-26636:In the Linux kernel, the following vulnerability has been resolved:
llc: make llc_ui_sendmsg() more robust against bonding changes
syzbot was able to trick llc_ui_sendmsg(), allocating an skb with no
headroom, but subsequently trying to push 14 bytes of Ethernet header [1]
Like some others, llc_ui_sendmsg() releases the socket lock before
calling sock_alloc_send_skb().
Then it acquires it again, but does not redo all the sanity checks
that were performed.
This fix:
- Uses LL_RESERVED_SPACE() to reserve space.
- Check all conditions again after socket lock is held again.
- Do not account Ethernet header for mtu limitation.
[1]
skbuff: skb_under_panic: text:ffff800088baa334 len:1514 put:14 head:ffff0000c9c37000 data:ffff0000c9c36ff2 tail:0x5dc end:0x6c0 dev:bond0
 kernel BUG at net/core/skbuff.c:193 !
Internal error: Oops - BUG: 00000000f2000800 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : skb_panic net/core/skbuff.c:189 [inline]
 pc : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
 lr : skb_panic net/core/skbuff.c:189 [inline]
 lr : skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
sp : ffff800096f97000
x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000
x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2
x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0
x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261ce
x17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001
x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000
x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400
x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000
x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714
x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089
Call trace:
  skb_panic net/core/skbuff.c:189 [inline]
  skb_under_panic+0x13c/0x140 net/core/skbuff.c:203
  skb_push+0xf0/0x108 net/core/skbuff.c:2451
  eth_header+0x44/0x1f8 net/ethernet/eth.c:83
  dev_hard_header include/linux/netdevice.h:3188 [inline]
  llc_mac_hdr_init+0x110/0x17c net/llc/llc_output.c:33
  llc_sap_action_send_xid_c+0x170/0x344 net/llc/llc_s_ac.c:85
  llc_exec_sap_trans_actions net/llc/llc_sap.c:153 [inline]
  llc_sap_next_state net/llc/llc_sap.c:182 [inline]
  llc_sap_state_process+0x1ec/0x774 net/llc/llc_sap.c:209
  llc_build_and_send_xid_pkt+0x12c/0x1c0 net/llc/llc_sap.c:270
  llc_ui_sendmsg+0x7bc/0xb1c net/llc/af_llc.c:997
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  sock_sendmsg+0x194/0x274 net/socket.c:767
  splice_to_socket+0x7cc/0xd58 fs/splice.c:881
  do_splice_from fs/splice.c:933 [inline]
  direct_splice_actor+0xe4/0x1c0 fs/splice.c:1142
  splice_direct_to_actor+0x2a0/0x7e4 fs/splice.c:1088
  do_splice_direct+0x20c/0x348 fs/splice.c:1194
  do_sendfile+0x4bc/0xc70 fs/read_write.c:1254
  __do_sys_sendfile64 fs/read_write.c:1322 [inline]
  __se_sys_sendfile64 fs/read_write.c:1308 [inline]
  __arm64_sys_sendfile64+0x160/0x3b4 fs/read_write.c:1308
  __invoke_syscall arch/arm64/kernel/syscall.c:37 [inline]
  invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:51
  el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:136
  do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:155
  el0_svc+0x54/0x158 arch/arm64/kernel/entry-common.c:678
  el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:696
  el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:595
Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)
CVE-2024-26640:In the Linux kernel, the following vulnerability has been resolved:
tcp: add sanity checks to rx zerocopy
TCP rx zerocopy intent is to map pages initially allocated
from NIC drivers, not pages owned by a fs.
This patch adds to can_map_frag() these additional checks:
- Page must not be a compound one.
- page-&gt;mapping must be NULL.
This fixes the panic reported by ZhangPeng.
syzbot was able to loopback packets built with sendfile(),
mapping pages owned by an ext4 file to TCP rx zerocopy.
r3 = socket$inet_tcp(0x2, 0x1, 0x0)
mmap(&amp;(0x7f0000ff9000/0x4000)=nil, 0x4000, 0x0, 0x12, r3, 0x0)
r4 = socket$inet_tcp(0x2, 0x1, 0x0)
bind$inet(r4, &amp;(0x7f0000000000)={0x2, 0x4e24, @multicast1}, 0x10)
connect$inet(r4, &amp;(0x7f00000006c0)={0x2, 0x4e24, @empty}, 0x10)
r5 = openat$dir(0xffffffffffffff9c, &amp;(0x7f00000000c0)='./file0\x00',
    0x181e42, 0x0)
fallocate(r5, 0x0, 0x0, 0x85b8)
sendfile(r4, r5, 0x0, 0x8ba0)
getsockopt$inet_tcp_TCP_ZEROCOPY_RECEIVE(r4, 0x6, 0x23,
    &amp;(0x7f00000001c0)={&amp;(0x7f0000ffb000/0x3000)=nil, 0x3000, 0x0, 0x0, 0x0,
    0x0, 0x0, 0x0, 0x0}, &amp;(0x7f0000000440)=0x40)
r6 = openat$dir(0xffffffffffffff9c, &amp;(0x7f00000000c0)='./file0\x00',
    0x181e42, 0x0)
CVE-2024-26641:In the Linux kernel, the following vulnerability has been resolved:
ip6_tunnel: make sure to pull inner header in __ip6_tnl_rcv()
syzbot found __ip6_tnl_rcv() could access unitiliazed data [1].
Call pskb_inet_may_pull() to fix this, and initialize ipv6h
variable after this call as it can change skb-&gt;head.
[1]
 BUG: KMSAN: uninit-value in __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
 BUG: KMSAN: uninit-value in INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
 BUG: KMSAN: uninit-value in IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
  __INET_ECN_decapsulate include/net/inet_ecn.h:253 [inline]
  INET_ECN_decapsulate include/net/inet_ecn.h:275 [inline]
  IP6_ECN_decapsulate+0x7df/0x1e50 include/net/inet_ecn.h:321
  ip6ip6_dscp_ecn_decapsulate+0x178/0x1b0 net/ipv6/ip6_tunnel.c:727
  __ip6_tnl_rcv+0xd4e/0x1590 net/ipv6/ip6_tunnel.c:845
  ip6_tnl_rcv+0xce/0x100 net/ipv6/ip6_tunnel.c:888
 gre_rcv+0x143f/0x1870
  ip6_protocol_deliver_rcu+0xda6/0x2a60 net/ipv6/ip6_input.c:438
  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
  dst_input include/net/dst.h:461 [inline]
  ip6_rcv_finish+0x5db/0x870 net/ipv6/ip6_input.c:79
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ipv6_rcv+0xda/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core net/core/dev.c:5532 [inline]
  __netif_receive_skb+0x1a6/0x5a0 net/core/dev.c:5646
  netif_receive_skb_internal net/core/dev.c:5732 [inline]
  netif_receive_skb+0x58/0x660 net/core/dev.c:5791
  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1555
  tun_get_user+0x53af/0x66d0 drivers/net/tun.c:2002
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
  call_write_iter include/linux/fs.h:2084 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0x786/0x1200 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xd0 fs/read_write.c:652
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
  slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
  slab_alloc_node mm/slub.c:3478 [inline]
  kmem_cache_alloc_node+0x5e9/0xb10 mm/slub.c:3523
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:560
  __alloc_skb+0x318/0x740 net/core/skbuff.c:651
  alloc_skb include/linux/skbuff.h:1286 [inline]
  alloc_skb_with_frags+0xc8/0xbd0 net/core/skbuff.c:6334
  sock_alloc_send_pskb+0xa80/0xbf0 net/core/sock.c:2787
  tun_alloc_skb drivers/net/tun.c:1531 [inline]
  tun_get_user+0x1e8a/0x66d0 drivers/net/tun.c:1846
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
  call_write_iter include/linux/fs.h:2084 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0x786/0x1200 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xd0 fs/read_write.c:652
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0x6d/0x140 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
CPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
CVE-2024-26642:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: disallow anonymous set with timeout flag
Anonymous sets are never used with timeout from userspace, reject this.
Exception to this rule is NFT_SET_EVAL to ensure legacy meters still work.
CVE-2024-26645:In the Linux kernel, the following vulnerability has been resolved:
tracing: Ensure visibility when inserting an element into tracing_map
Running the following two commands in parallel on a multi-processor
AArch64 machine can sporadically produce an unexpected warning about
duplicate histogram entries:
 $ while true; do
     echo hist:key=id.syscall:val=hitcount &gt; \
       /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/trigger
     cat /sys/kernel/debug/tracing/events/raw_syscalls/sys_enter/hist
     sleep 0.001
   done
 $ stress-ng --sysbadaddr $(nproc)
The warning looks as follows:
[ 2911.172474] ------------[ cut here ]------------
[ 2911.173111] Duplicates detected: 1
[ 2911.173574] WARNING: CPU: 2 PID: 12247 at kernel/trace/tracing_map.c:983 tracing_map_sort_entries+0x3e0/0x408
[ 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)
[ 2911.174738] Unloaded tainted modules: cppc_cpufreq(E):1
[ 2911.180985] CPU: 2 PID: 12247 Comm: cat Kdump: loaded Tainted: G            E      6.7.0-default #2 1b58bbb22c97e4399dc09f92d309344f69c44a01
[ 2911.182398] Hardware name: Amazon EC2 c7g.8xlarge/, BIOS 1.0 11/1/2018
[ 2911.183208] pstate: 61400005 (nZCv daif +PAN -UAO -TCO +DIT -SSBS BTYPE=--)
[ 2911.184038] pc : tracing_map_sort_entries+0x3e0/0x408
[ 2911.184667] lr : tracing_map_sort_entries+0x3e0/0x408
[ 2911.185310] sp : ffff8000a1513900
[ 2911.185750] x29: ffff8000a1513900 x28: ffff0003f272fe80 x27: 0000000000000001
[ 2911.186600] x26: ffff0003f272fe80 x25: 0000000000000030 x24: 0000000000000008
[ 2911.187458] x23: ffff0003c5788000 x22: ffff0003c16710c8 x21: ffff80008017f180
[ 2911.188310] x20: ffff80008017f000 x19: ffff80008017f180 x18: ffffffffffffffff
[ 2911.189160] x17: 0000000000000000 x16: 0000000000000000 x15: ffff8000a15134b8
[ 2911.190015] x14: 0000000000000000 x13: 205d373432323154 x12: 5b5d313131333731
[ 2911.190844] x11: 00000000fffeffff x10: 00000000fffeffff x9 : ffffd1b78274a13c
[ 2911.191716] x8 : 000000000017ffe8 x7 : c0000000fffeffff x6 : 000000000057ffa8
[ 2911.192554] x5 : ffff0012f6c24ec0 x4 : 0000000000000000 x3 : ffff2e5b72b5d000
[ 2911.193404] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff0003ff254480
[ 2911.194259] Call trace:
[ 2911.194626]  tracing_map_sort_entries+0x3e0/0x408
[ 2911.195220]  hist_show+0x124/0x800
[ 2911.195692]  seq_read_iter+0x1d4/0x4e8
[ 2911.196193]  seq_read+0xe8/0x138
[ 2911.196638]  vfs_read+0xc8/0x300
[ 2911.197078]  ksys_read+0x70/0x108
[ 2911.197534]  __arm64_sys_read+0x24/0x38
[ 2911.198046]  invoke_syscall+0x78/0x108
[ 2911.198553]  el0_svc_common.constprop.0+0xd0/0xf8
[ 2911.199157]  do_el0_svc+0x28/0x40
[ 2911.199613]  el0_svc+0x40/0x178
[ 2911.200048]  el0t_64_sync_handler+0x13c/0x158
[ 2911.200621]  el0t_64_sync+0x1a8/0x1b0
[ 2911.201115] ---[ end trace 0000000000000000 ]---
The problem appears to be caused by CPU reordering of writes issued from
__tracing_map_insert().
The check for the presence of an element with a given key in this
function is:
 val = READ_ONCE(entry-&gt;val);
 if (val &amp;&amp; keys_match(key, val-&gt;key, map-&gt;key_size)) ...
The write of a new entry is:
 elt = get_free_elt(map);
 memcpy(elt-&gt;key, key, map-&gt;key_size);
 entry-&gt;val = elt;
The &quot;memcpy(elt-&gt;key, key, map-&gt;key_size);&quot; and &quot;entry-&gt;val = elt;&quot;
stores may become visible in the reversed order on another CPU. This
second CPU might then incorrectly determine that a new key doesn't match
an already present val-&gt;key and subse
---truncated---
CVE-2024-26661:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'
In &quot;u32 otg_inst = pipe_ctx-&gt;stream_res.tg-&gt;inst;&quot;
pipe_ctx-&gt;stream_res.tg could be NULL, it is relying on the caller to
ensure the tg is not NULL.
CVE-2024-26665:In the Linux kernel, the following vulnerability has been resolved:
tunnels: fix out of bounds access when building IPv6 PMTU error
If the ICMPv6 error is built from a non-linear skb we get the following
splat,
  BUG: KASAN: slab-out-of-bounds in do_csum+0x220/0x240
  Read of size 4 at addr ffff88811d402c80 by task netperf/820
  CPU: 0 PID: 820 Comm: netperf Not tainted 6.8.0-rc1+ #543
  ...
   kasan_report+0xd8/0x110
   do_csum+0x220/0x240
   csum_partial+0xc/0x20
   skb_tunnel_check_pmtu+0xeb9/0x3280
   vxlan_xmit_one+0x14c2/0x4080
   vxlan_xmit+0xf61/0x5c00
   dev_hard_start_xmit+0xfb/0x510
   __dev_queue_xmit+0x7cd/0x32a0
   br_dev_queue_push_xmit+0x39d/0x6a0
Use skb_checksum instead of csum_partial who cannot deal with non-linear
SKBs.
CVE-2024-26675:In the Linux kernel, the following vulnerability has been resolved:
ppp_async: limit MRU to 64K
syzbot triggered a warning [1] in __alloc_pages():
WARN_ON_ONCE_GFP(order &gt; MAX_PAGE_ORDER, gfp)
Willem fixed a similar issue in commit c0a2a1b0d631 (&quot;ppp: limit MRU to 64K&quot;)
Adopt the same sanity check for ppp_async_ioctl(PPPIOCSMRU)
[1]:
 WARNING: CPU: 1 PID: 11 at mm/page_alloc.c:4543 __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
Modules linked in:
CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023
Workqueue: events_unbound flush_to_ldisc
pstate: 204000c5 (nzCv daIF +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
 lr : __alloc_pages+0xc8/0x698 mm/page_alloc.c:4537
sp : ffff800093967580
x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000
x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0
x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8
x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120
x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005
x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000
x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001
x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003f
x5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020
x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0
Call trace:
  __alloc_pages+0x308/0x698 mm/page_alloc.c:4543
  __alloc_pages_node include/linux/gfp.h:238 [inline]
  alloc_pages_node include/linux/gfp.h:261 [inline]
  __kmalloc_large_node+0xbc/0x1fc mm/slub.c:3926
  __do_kmalloc_node mm/slub.c:3969 [inline]
  __kmalloc_node_track_caller+0x418/0x620 mm/slub.c:4001
  kmalloc_reserve+0x17c/0x23c net/core/skbuff.c:590
  __alloc_skb+0x1c8/0x3d8 net/core/skbuff.c:651
  __netdev_alloc_skb+0xb8/0x3e8 net/core/skbuff.c:715
  netdev_alloc_skb include/linux/skbuff.h:3235 [inline]
  dev_alloc_skb include/linux/skbuff.h:3248 [inline]
  ppp_async_input drivers/net/ppp/ppp_async.c:863 [inline]
  ppp_asynctty_receive+0x588/0x186c drivers/net/ppp/ppp_async.c:341
  tty_ldisc_receive_buf+0x12c/0x15c drivers/tty/tty_buffer.c:390
  tty_port_default_receive_buf+0x74/0xac drivers/tty/tty_port.c:37
  receive_buf drivers/tty/tty_buffer.c:444 [inline]
  flush_to_ldisc+0x284/0x6e4 drivers/tty/tty_buffer.c:494
  process_one_work+0x694/0x1204 kernel/workqueue.c:2633
  process_scheduled_works kernel/workqueue.c:2706 [inline]
  worker_thread+0x938/0xef4 kernel/workqueue.c:2787
  kthread+0x288/0x310 kernel/kthread.c:388
  ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:860
CVE-2024-26679:In the Linux kernel, the following vulnerability has been resolved:
inet: read sk-&gt;sk_family once in inet_recv_error()
inet_recv_error() is called without holding the socket lock.
IPv6 socket could mutate to IPv4 with IPV6_ADDRFORM
socket option and trigger a KCSAN warning.
CVE-2024-26684:In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: xgmac: fix handling of DPP safety error for DMA channels
Commit 56e58d6c8a56 (&quot;net: stmmac: Implement Safety Features in
XGMAC core&quot;) checks and reports safety errors, but leaves the
Data Path Parity Errors for each channel in DMA unhandled at all, lead to
a storm of interrupt.
Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.
CVE-2024-26685:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential bug in end_buffer_async_write
According to a syzbot report, end_buffer_async_write(), which handles the
completion of block device writes, may detect abnormal condition of the
buffer async_write flag and cause a BUG_ON failure when using nilfs2.
Nilfs2 itself does not use end_buffer_async_write().  But, the async_write
flag is now used as a marker by commit 7f42ec394156 (&quot;nilfs2: fix issue
with race condition of competition between segments for dirty blocks&quot;) as
a means of resolving double list insertion of dirty blocks in
nilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and the
resulting crash.
This modification is safe as long as it is used for file data and b-tree
node blocks where the page caches are independent.  However, it was
irrelevant and redundant to also introduce async_write for segment summary
and super root blocks that share buffers with the backing device.  This
led to the possibility that the BUG_ON check in end_buffer_async_write
would fail as described above, if independent writebacks of the backing
device occurred in parallel.
The use of async_write for segment summary buffers has already been
removed in a previous change.
Fix this issue by removing the manipulation of the async_write flag for
the remaining super root block buffer.
CVE-2024-26686:In the Linux kernel, the following vulnerability has been resolved:
fs/proc: do_task_stat: use sig-&gt;stats_lock to gather the threads/children stats
lock_task_sighand() can trigger a hard lockup.  If NR_CPUS threads call
do_task_stat() at the same time and the process has NR_THREADS, it will
spin with irqs disabled O(NR_CPUS * NR_THREADS) time.
Change do_task_stat() to use sig-&gt;stats_lock to gather the statistics
outside of -&gt;siglock protected section, in the likely case this code will
run lockless.
CVE-2024-26697:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix data corruption in dsync block recovery for small block sizes
The helper function nilfs_recovery_copy_block() of
nilfs_recovery_dsync_blocks(), which recovers data from logs created by
data sync writes during a mount after an unclean shutdown, incorrectly
calculates the on-page offset when copying repair data to the file's page
cache.  In environments where the block size is smaller than the page
size, this flaw can cause data corruption and leak uninitialized memory
bytes during the recovery process.
Fix these issues by correcting this byte offset calculation on the page.
CVE-2024-26702:In the Linux kernel, the following vulnerability has been resolved:
iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRC
Recently, we encounter kernel crash in function rm3100_common_probe
caused by out of bound access of array rm3100_samp_rates (because of
underlying hardware failures). Add boundary check to prevent out of
bound access.
CVE-2024-26706:In the Linux kernel, the following vulnerability has been resolved:
parisc: Fix random data corruption from exception handler
The current exception handler implementation, which assists when accessing
user space memory, may exhibit random data corruption if the compiler decides
to use a different register than the specified register %r29 (defined in
ASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose another
register, the fault handler will nevertheless store -EFAULT into %r29 and thus
trash whatever this register is used for.
Looking at the assembly I found that this happens sometimes in emulate_ldd().
To solve the issue, the easiest solution would be if it somehow is
possible to tell the fault handler which register is used to hold the error
code. Using %0 or %1 in the inline assembly is not posssible as it will show
up as e.g. %r29 (with the &quot;%r&quot; prefix), which the GNU assembler can not
convert to an integer.
This patch takes another, better and more flexible approach:
We extend the __ex_table (which is out of the execution path) by one 32-word.
In this word we tell the compiler to insert the assembler instruction
&quot;or %r0,%r0,%reg&quot;, where %reg references the register which the compiler
choosed for the error return code.
In case of an access failure, the fault handler finds the __ex_table entry and
can examine the opcode. The used register is encoded in the lowest 5 bits, and
the fault handler can then store -EFAULT into this register.
Since we extend the __ex_table to 3 words we can't use the BUILDTIME_TABLE_SORT
config option any longer.
CVE-2024-26707:In the Linux kernel, the following vulnerability has been resolved:
net: hsr: remove WARN_ONCE() in send_hsr_supervision_frame()
Syzkaller reported [1] hitting a warning after failing to allocate
resources for skb in hsr_init_skb(). Since a WARN_ONCE() call will
not help much in this case, it might be prudent to switch to
netdev_warn_once(). At the very least it will suppress syzkaller
reports such as [1].
Just in case, use netdev_warn_once() in send_prp_supervision_frame()
for similar reasons.
[1]
HSR: Could not send supervision frame
WARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
RIP: 0010:send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294
...
Call Trace:
 &lt;IRQ&gt;
 hsr_announce+0x114/0x370 net/hsr/hsr_device.c:382
 call_timer_fn+0x193/0x590 kernel/time/timer.c:1700
 expire_timers kernel/time/timer.c:1751 [inline]
 __run_timers+0x764/0xb20 kernel/time/timer.c:2022
 run_timer_softirq+0x58/0xd0 kernel/time/timer.c:2035
 __do_softirq+0x21a/0x8de kernel/softirq.c:553
 invoke_softirq kernel/softirq.c:427 [inline]
 __irq_exit_rcu kernel/softirq.c:632 [inline]
 irq_exit_rcu+0xb7/0x120 kernel/softirq.c:644
 sysvec_apic_timer_interrupt+0x95/0xb0 arch/x86/kernel/apic/apic.c:1076
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:649
...
This issue is also found in older kernels (at least up to 5.10).
CVE-2024-26712:In the Linux kernel, the following vulnerability has been resolved:
powerpc/kasan: Fix addr error caused by page alignment
In kasan_init_region, when k_start is not page aligned, at the begin of
for loop, k_cur = k_start &amp; PAGE_MASK is less than k_start, and then
`va = block + k_cur - k_start` is less than block, the addr va is invalid,
because the memory address space from va to block is not alloced by
memblock_alloc, which will not be reserved by memblock_reserve later, it
will be used by other places.
As a result, memory overwriting occurs.
for example:
int __init __weak kasan_init_region(void *start, size_t size)
{
[...]
	/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */
	block = memblock_alloc(k_end - k_start, PAGE_SIZE);
	[...]
	for (k_cur = k_start &amp; PAGE_MASK; k_cur &lt; k_end; k_cur += PAGE_SIZE) {
		/* at the begin of for loop
		 * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)
		 * va(dcd96c00) is less than block(dcd97000), va is invalid
		 */
		void *va = block + k_cur - k_start;
		[...]
	}
[...]
}
Therefore, page alignment is performed on k_start before
memblock_alloc() to ensure the validity of the VA address.
CVE-2024-26720:In the Linux kernel, the following vulnerability has been resolved:
mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again
(struct dirty_throttle_control *)-&gt;thresh is an unsigned long, but is
passed as the u32 divisor argument to div_u64().  On architectures where
unsigned long is 64 bytes, the argument will be implicitly truncated.
Use div64_u64() instead of div_u64() so that the value used in the &quot;is
this a safe division&quot; check is the same as the divisor.
Also, remove redundant cast of the numerator to u64, as that should happen
implicitly.
This would be difficult to exploit in memcg domain, given the ratio-based
arithmetic domain_drity_limits() uses, but is much easier in global
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)
CVE-2024-26726:In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't drop extent_map for free space inode on write error
While running the CI for an unrelated change I hit the following panic
with generic/648 on btrfs_holes_spacecache.
assertion failed: block_start != EXTENT_MAP_HOLE, in fs/btrfs/extent_io.c:1385
------------[ cut here ]------------
kernel BUG at fs/btrfs/extent_io.c:1385!
invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1
RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0
Call Trace:
 &lt;TASK&gt;
 extent_write_cache_pages+0x2ac/0x8f0
 extent_writepages+0x87/0x110
 do_writepages+0xd5/0x1f0
 filemap_fdatawrite_wbc+0x63/0x90
 __filemap_fdatawrite_range+0x5c/0x80
 btrfs_fdatawrite_range+0x1f/0x50
 btrfs_write_out_cache+0x507/0x560
 btrfs_write_dirty_block_groups+0x32a/0x420
 commit_cowonly_roots+0x21b/0x290
 btrfs_commit_transaction+0x813/0x1360
 btrfs_sync_file+0x51a/0x640
 __x64_sys_fdatasync+0x52/0x90
 do_syscall_64+0x9c/0x190
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
This happens because we fail to write out the free space cache in one
instance, come back around and attempt to write it again.  However on
the second pass through we go to call btrfs_get_extent() on the inode to
get the extent mapping.  Because this is a new block group, and with the
free space inode we always search the commit root to avoid deadlocking
with the tree, we find nothing and return a EXTENT_MAP_HOLE for the
requested range.
This happens because the first time we try to write the space cache out
we hit an error, and on an error we drop the extent mapping.  This is
normal for normal files, but the free space cache inode is special.  We
always expect the extent map to be correct.  Thus the second time
through we end up with a bogus extent map.
Since we're deprecating this feature, the most straightforward way to
fix this is to simply skip dropping the extent map range for this failed
range.
I shortened the test by using error injection to stress the area to make
it easier to reproduce.  With this patch in place we no longer panic
with my error injection test.
CVE-2024-26733:In the Linux kernel, the following vulnerability has been resolved:
arp: Prevent overflow in arp_req_get().
syzkaller reported an overflown write in arp_req_get(). [0]
When ioctl(SIOCGARP) is issued, arp_req_get() looks up an neighbour
entry and copies neigh-&gt;ha to struct arpreq.arp_ha.sa_data.
The arp_ha here is struct sockaddr, not struct sockaddr_storage, so
the sa_data buffer is just 14 bytes.
In the splat below, 2 bytes are overflown to the next int field,
arp_flags.  We initialise the field just after the memcpy(), so it's
not a problem.
However, when dev-&gt;addr_len is greater than 22 (e.g. MAX_ADDR_LEN),
arp_netmask is overwritten, which could be set as htonl(0xFFFFFFFFUL)
in arp_ioctl() before calling arp_req_get().
To avoid the overflow, let's limit the max length of memcpy().
Note that commit b5f0de6df6dc (&quot;net: dev: Convert sa_data to flexible
array in struct sockaddr&quot;) just silenced syzkaller.
[0]:
memcpy: detected field-spanning write (size 16) of single field &quot;r-&gt;arp_ha.sa_data&quot; at net/ipv4/arp.c:1128 (size 14)
WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
Modules linked in:
CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014
RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128
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
RSP: 0018:ffffc900050b7998 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001
RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000
R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010
FS:  00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 arp_ioctl+0x33f/0x4b0 net/ipv4/arp.c:1261
 inet_ioctl+0x314/0x3a0 net/ipv4/af_inet.c:981
 sock_do_ioctl+0xdf/0x260 net/socket.c:1204
 sock_ioctl+0x3ef/0x650 net/socket.c:1321
 vfs_ioctl fs/ioctl.c:51 [inline]
 __do_sys_ioctl fs/ioctl.c:870 [inline]
 __se_sys_ioctl fs/ioctl.c:856 [inline]
 __x64_sys_ioctl+0x18e/0x220 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:51 [inline]
 do_syscall_64+0x37/0x90 arch/x86/entry/common.c:81
 entry_SYSCALL_64_after_hwframe+0x64/0xce
RIP: 0033:0x7f172b262b8d
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
RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8d
RDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003
RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000
 &lt;/TASK&gt;
CVE-2024-26734:In the Linux kernel, the following vulnerability has been resolved:
devlink: fix possible use-after-free and memory leaks in devlink_init()
The pernet operations structure for the subsystem must be registered
before registering the generic netlink family.
Make an unregister in case of unsuccessful registration.
CVE-2024-26735:In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix possible use-after-free and null-ptr-deref
The pernet operations structure for the subsystem must be registered
before registering the generic netlink family.
CVE-2024-26740:In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mirred: use the backlog for mirred ingress
The test Davide added in commit ca22da2fbd69 (&quot;act_mirred: use the backlog
for nested calls to mirred ingress&quot;) hangs our testing VMs every 10 or so
runs, with the familiar tcp_v4_rcv -&gt; tcp_v4_rcv deadlock reported by
lockdep.
The problem as previously described by Davide (see Link) is that
if we reverse flow of traffic with the redirect (egress -&gt; ingress)
we may reach the same socket which generated the packet. And we may
still be holding its socket lock. The common solution to such deadlocks
is to put the packet in the Rx backlog, rather than run the Rx path
inline. Do that for all egress -&gt; ingress reversals, not just once
we started to nest mirred calls.
In the past there was a concern that the backlog indirection will
lead to loss of error reporting / less accurate stats. But the current
workaround does not seem to address the issue.
CVE-2024-26743:In the Linux kernel, the following vulnerability has been resolved:
RDMA/qedr: Fix qedr_create_user_qp error flow
Avoid the following warning by making sure to free the allocated
resources in case that qedr_init_user_queue() fail.
-----------[ cut here ]-----------
WARNING: CPU: 0 PID: 143192 at drivers/infiniband/core/rdma_core.c:874 uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
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
ghash_clmulni_intel megaraid_sas crc8 wmi [last unloaded: ib_srpt]
CPU: 0 PID: 143192 Comm: fi_rdm_tagged_p Kdump: loaded Not tainted 5.14.0-408.el9.x86_64 #1
Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022
RIP: 0010:uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
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
RSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286
RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016
RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600
RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000
R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80
R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000
FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0
Call Trace:
&lt;TASK&gt;
? show_trace_log_lvl+0x1c4/0x2df
? show_trace_log_lvl+0x1c4/0x2df
? ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
? __warn+0x81/0x110
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
? report_bug+0x10a/0x140
? handle_bug+0x3c/0x70
? exc_invalid_op+0x14/0x70
? asm_exc_invalid_op+0x16/0x20
? uverbs_destroy_ufile_hw+0xcf/0xf0 [ib_uverbs]
ib_uverbs_close+0x1f/0xb0 [ib_uverbs]
__fput+0x94/0x250
task_work_run+0x5c/0x90
do_exit+0x270/0x4a0
do_group_exit+0x2d/0x90
get_signal+0x87c/0x8c0
arch_do_signal_or_restart+0x25/0x100
? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]
exit_to_user_mode_loop+0x9c/0x130
exit_to_user_mode_prepare+0xb6/0x100
syscall_exit_to_user_mode+0x12/0x40
do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? syscall_exit_work+0x103/0x130
? syscall_exit_to_user_mode+0x22/0x40
? do_syscall_64+0x69/0x90
? do_syscall_64+0x69/0x90
? common_interrupt+0x43/0xa0
entry_SYSCALL_64_after_hwframe+0x72/0xdc
RIP: 0033:0x1470abe3ec6b
Code: Unable to access opcode bytes at RIP 0x1470abe3ec41.
RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010
RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6b
RDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004
RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00
R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358
R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470
&lt;/TASK&gt;
--[ end trace 888a9b92e04c5c97 ]--
CVE-2024-26744:In the Linux kernel, the following vulnerability has been resolved:
RDMA/srpt: Support specifying the srpt_service_guid parameter
Make loading ib_srpt with this parameter set work. The current behavior is
that setting that parameter while loading the ib_srpt kernel module
triggers the following kernel crash:
BUG: kernel NULL pointer dereference, address: 0000000000000000
Call Trace:
 &lt;TASK&gt;
 parse_one+0x18c/0x1d0
 parse_args+0xe1/0x230
 load_module+0x8de/0xa60
 init_module_from_file+0x8b/0xd0
 idempotent_init_module+0x181/0x240
 __x64_sys_finit_module+0x5a/0xb0
 do_syscall_64+0x5f/0xe0
 entry_SYSCALL_64_after_hwframe+0x6e/0x76
CVE-2024-26754:In the Linux kernel, the following vulnerability has been resolved:
gtp: fix use-after-free and null-ptr-deref in gtp_genl_dump_pdp()
The gtp_net_ops pernet operations structure for the subsystem must be
registered before registering the generic netlink family.
Syzkaller hit 'general protection fault in gtp_genl_dump_pdp' bug:
general protection fault, probably for non-canonical address
0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTI
KASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]
CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014
RIP: 0010:gtp_genl_dump_pdp+0x1be/0x800 [gtp]
Code: c6 89 c6 e8 64 e9 86 df 58 45 85 f6 0f 85 4e 04 00 00 e8 c5 ee 86
      df 48 8b 54 24 18 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 &lt;80&gt;
      3c 02 00 0f 85 de 05 00 00 48 8b 44 24 18 4c 8b 30 4c 39 f0 74
RSP: 0018:ffff888014107220 EFLAGS: 00010202
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000
R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000
FS:  00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? show_regs+0x90/0xa0
 ? die_addr+0x50/0xd0
 ? exc_general_protection+0x148/0x220
 ? asm_exc_general_protection+0x22/0x30
 ? gtp_genl_dump_pdp+0x1be/0x800 [gtp]
 ? __alloc_skb+0x1dd/0x350
 ? __pfx___alloc_skb+0x10/0x10
 genl_dumpit+0x11d/0x230
 netlink_dump+0x5b9/0xce0
 ? lockdep_hardirqs_on_prepare+0x253/0x430
 ? __pfx_netlink_dump+0x10/0x10
 ? kasan_save_track+0x10/0x40
 ? __kasan_kmalloc+0x9b/0xa0
 ? genl_start+0x675/0x970
 __netlink_dump_start+0x6fc/0x9f0
 genl_family_rcv_msg_dumpit+0x1bb/0x2d0
 ? __pfx_genl_family_rcv_msg_dumpit+0x10/0x10
 ? genl_op_from_small+0x2a/0x440
 ? cap_capable+0x1d0/0x240
 ? __pfx_genl_start+0x10/0x10
 ? __pfx_genl_dumpit+0x10/0x10
 ? __pfx_genl_done+0x10/0x10
 ? security_capable+0x9d/0xe0
CVE-2024-26763:In the Linux kernel, the following vulnerability has been resolved:
dm-crypt: don't modify the data when using authenticated encryption
It was said that authenticated encryption could produce invalid tag when
the data that is being encrypted is modified [1]. So, fix this problem by
copying the data into the clone bio first and then encrypt them inside the
clone bio.
This may reduce performance, but it is needed to prevent the user from
corrupting the device by writing data with O_DIRECT and modifying them at
the same time.
[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/
CVE-2024-26776:In the Linux kernel, the following vulnerability has been resolved:
spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detected
Return IRQ_NONE from the interrupt handler when no interrupt was
detected. Because an empty interrupt will cause a null pointer error:
    Unable to handle kernel NULL pointer dereference at virtual
  address 0000000000000008
    Call trace:
        complete+0x54/0x100
        hisi_sfc_v3xx_isr+0x2c/0x40 [spi_hisi_sfc_v3xx]
        __handle_irq_event_percpu+0x64/0x1e0
        handle_irq_event+0x7c/0x1cc
CVE-2024-26782:In the Linux kernel, the following vulnerability has been resolved:
mptcp: fix double-free on socket dismantle
when MPTCP server accepts an incoming connection, it clones its listener
socket. However, the pointer to 'inet_opt' for the new socket has the same
value as the original one: as a consequence, on program exit it's possible
to observe the following splat:
  BUG: KASAN: double-free in inet_sock_destruct+0x54f/0x8b0
  Free of addr ffff888485950880 by task swapper/25/0
  CPU: 25 PID: 0 Comm: swapper/25 Kdump: loaded Not tainted 6.8.0-rc1+ #609
  Hardware name: Supermicro SYS-6027R-72RF/X9DRH-7TF/7F/iTF/iF, BIOS 3.0  07/26/2013
  Call Trace:
   &lt;IRQ&gt;
   dump_stack_lvl+0x32/0x50
   print_report+0xca/0x620
   kasan_report_invalid_free+0x64/0x90
   __kasan_slab_free+0x1aa/0x1f0
   kfree+0xed/0x2e0
   inet_sock_destruct+0x54f/0x8b0
   __sk_destruct+0x48/0x5b0
   rcu_do_batch+0x34e/0xd90
   rcu_core+0x559/0xac0
   __do_softirq+0x183/0x5a4
   irq_exit_rcu+0x12d/0x170
   sysvec_apic_timer_interrupt+0x6b/0x80
   &lt;/IRQ&gt;
   &lt;TASK&gt;
   asm_sysvec_apic_timer_interrupt+0x16/0x20
  RIP: 0010:cpuidle_enter_state+0x175/0x300
  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
  RSP: 0018:ffff888481cf7d90 EFLAGS: 00000202
  RAX: 0000000000000000 RBX: ffff88887facddc8 RCX: 0000000000000000
  RDX: 1ffff1110ff588b1 RSI: 0000000000000019 RDI: ffff88887fac4588
  RBP: 0000000000000004 R08: 0000000000000002 R09: 0000000000043080
  R10: 0009b02ea273363f R11: ffff88887fabf42b R12: ffffffff932592e0
  R13: 0000000000000004 R14: 0000000000000000 R15: 00000022c880ec80
   cpuidle_enter+0x4a/0xa0
   do_idle+0x310/0x410
   cpu_startup_entry+0x51/0x60
   start_secondary+0x211/0x270
   secondary_startup_64_no_verify+0x184/0x18b
   &lt;/TASK&gt;
  Allocated by task 6853:
   kasan_save_stack+0x1c/0x40
   kasan_save_track+0x10/0x30
   __kasan_kmalloc+0xa6/0xb0
   __kmalloc+0x1eb/0x450
   cipso_v4_sock_setattr+0x96/0x360
   netlbl_sock_setattr+0x132/0x1f0
   selinux_netlbl_socket_post_create+0x6c/0x110
   selinux_socket_post_create+0x37b/0x7f0
   security_socket_post_create+0x63/0xb0
   __sock_create+0x305/0x450
   __sys_socket_create.part.23+0xbd/0x130
   __sys_socket+0x37/0xb0
   __x64_sys_socket+0x6f/0xb0
   do_syscall_64+0x83/0x160
   entry_SYSCALL_64_after_hwframe+0x6e/0x76
  Freed by task 6858:
   kasan_save_stack+0x1c/0x40
   kasan_save_track+0x10/0x30
   kasan_save_free_info+0x3b/0x60
   __kasan_slab_free+0x12c/0x1f0
   kfree+0xed/0x2e0
   inet_sock_destruct+0x54f/0x8b0
   __sk_destruct+0x48/0x5b0
   subflow_ulp_release+0x1f0/0x250
   tcp_cleanup_ulp+0x6e/0x110
   tcp_v4_destroy_sock+0x5a/0x3a0
   inet_csk_destroy_sock+0x135/0x390
   tcp_fin+0x416/0x5c0
   tcp_data_queue+0x1bc8/0x4310
   tcp_rcv_state_process+0x15a3/0x47b0
   tcp_v4_do_rcv+0x2c1/0x990
   tcp_v4_rcv+0x41fb/0x5ed0
   ip_protocol_deliver_rcu+0x6d/0x9f0
   ip_local_deliver_finish+0x278/0x360
   ip_local_deliver+0x182/0x2c0
   ip_rcv+0xb5/0x1c0
   __netif_receive_skb_one_core+0x16e/0x1b0
   process_backlog+0x1e3/0x650
   __napi_poll+0xa6/0x500
   net_rx_action+0x740/0xbb0
   __do_softirq+0x183/0x5a4
  The buggy address belongs to the object at ffff888485950880
   which belongs to the cache kmalloc-64 of size 64
  The buggy address is located 0 bytes inside of
   64-byte region [ffff888485950880, ffff8884859508c0)
  The buggy address belongs to the physical page:
  page:0000000056d1e95e refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888485950700 pfn:0x485950
  flags: 0x57ffffc0000800(slab|node=1|zone=2|lastcpupid=0x1fffff)
  page_type: 0xffffffff()
  raw: 0057ffffc0000800 ffff88810004c640 ffffea00121b8ac0 dead000000000006
  raw: ffff888485950700 0000000000200019 00000001ffffffff 0000000000000000
  page dumped because: kasan: bad access detected
  Memory state around the buggy address:
   ffff888485950780: fa fb fb
---truncated---
CVE-2024-26787:In the Linux kernel, the following vulnerability has been resolved:
mmc: mmci: stm32: fix DMA API overlapping mappings warning
Turning on CONFIG_DMA_API_DEBUG_SG results in the following warning:
DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,
overlapping mappings aren't supported
WARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568
add_dma_entry+0x234/0x2f4
Modules linked in:
CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1
Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)
Workqueue: events_freezable mmc_rescan
Call trace:
add_dma_entry+0x234/0x2f4
debug_dma_map_sg+0x198/0x350
__dma_map_sg_attrs+0xa0/0x110
dma_map_sg_attrs+0x10/0x2c
sdmmc_idma_prep_data+0x80/0xc0
mmci_prep_data+0x38/0x84
mmci_start_data+0x108/0x2dc
mmci_request+0xe4/0x190
__mmc_start_request+0x68/0x140
mmc_start_request+0x94/0xc0
mmc_wait_for_req+0x70/0x100
mmc_send_tuning+0x108/0x1ac
sdmmc_execute_tuning+0x14c/0x210
mmc_execute_tuning+0x48/0xec
mmc_sd_init_uhs_card.part.0+0x208/0x464
mmc_sd_init_card+0x318/0x89c
mmc_attach_sd+0xe4/0x180
mmc_rescan+0x244/0x320
DMA API debug brings to light leaking dma-mappings as dma_map_sg and
dma_unmap_sg are not correctly balanced.
If an error occurs in mmci_cmd_irq function, only mmci_dma_error
function is called and as this API is not managed on stm32 variant,
dma_unmap_sg is never called in this error path.
CVE-2024-26801:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Avoid potential use-after-free in hci_error_reset
While handling the HCI_EV_HARDWARE_ERROR event, if the underlying
BT controller is not responding, the GPIO reset mechanism would
free the hci_dev and lead to a use-after-free in hci_error_reset.
Here's the call trace observed on a ChromeOS device with Intel AX201:
   queue_work_on+0x3e/0x6c
   __hci_cmd_sync_sk+0x2ee/0x4c0 [bluetooth &lt;HASH:3b4a6&gt;]
   ? init_wait_entry+0x31/0x31
   __hci_cmd_sync+0x16/0x20 [bluetooth &lt;HASH:3b4a 6&gt;]
   hci_error_reset+0x4f/0xa4 [bluetooth &lt;HASH:3b4a 6&gt;]
   process_one_work+0x1d8/0x33f
   worker_thread+0x21b/0x373
   kthread+0x13a/0x152
   ? pr_cont_work+0x54/0x54
   ? kthread_blkcg+0x31/0x31
    ret_from_fork+0x1f/0x30
This patch holds the reference count on the hci_dev while processing
a HCI_EV_HARDWARE_ERROR event to avoid potential crash.
CVE-2024-26805:In the Linux kernel, the following vulnerability has been resolved:
netlink: Fix kernel-infoleak-after-free in __skb_datagram_iter
syzbot reported the following uninit-value access issue [1]:
netlink_to_full_skb() creates a new `skb` and puts the `skb-&gt;data`
passed as a 1st arg of netlink_to_full_skb() onto new `skb`. The data
size is specified as `len` and passed to skb_put_data(). This `len`
is based on `skb-&gt;end` that is not data offset but buffer offset. The
`skb-&gt;end` contains data and tailroom. Since the tailroom is not
initialized when the new `skb` created, KMSAN detects uninitialized
memory area when copying the data.
This patch resolved this issue by correct the len from `skb-&gt;end` to
`skb-&gt;len`, which is the actual data offset.
BUG: KMSAN: kernel-infoleak-after-free in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak-after-free in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_ubuf include/linux/iov_iter.h:29 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
BUG: KMSAN: kernel-infoleak-after-free in iterate_and_advance include/linux/iov_iter.h:271 [inline]
BUG: KMSAN: kernel-infoleak-after-free in _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
 instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 copy_to_user_iter lib/iov_iter.c:24 [inline]
 iterate_ubuf include/linux/iov_iter.h:29 [inline]
 iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
 iterate_and_advance include/linux/iov_iter.h:271 [inline]
 _copy_to_iter+0x364/0x2520 lib/iov_iter.c:186
 copy_to_iter include/linux/uio.h:197 [inline]
 simple_copy_to_iter+0x68/0xa0 net/core/datagram.c:532
 __skb_datagram_iter+0x123/0xdc0 net/core/datagram.c:420
 skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546
 skb_copy_datagram_msg include/linux/skbuff.h:3960 [inline]
 packet_recvmsg+0xd9c/0x2000 net/packet/af_packet.c:3482
 sock_recvmsg_nosec net/socket.c:1044 [inline]
 sock_recvmsg net/socket.c:1066 [inline]
 sock_read_iter+0x467/0x580 net/socket.c:1136
 call_read_iter include/linux/fs.h:2014 [inline]
 new_sync_read fs/read_write.c:389 [inline]
 vfs_read+0x8f6/0xe00 fs/read_write.c:470
 ksys_read+0x20f/0x4c0 fs/read_write.c:613
 __do_sys_read fs/read_write.c:623 [inline]
 __se_sys_read fs/read_write.c:621 [inline]
 __x64_sys_read+0x93/0xd0 fs/read_write.c:621
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was stored to memory at:
 skb_put_data include/linux/skbuff.h:2622 [inline]
 netlink_to_full_skb net/netlink/af_netlink.c:181 [inline]
 __netlink_deliver_tap_skb net/netlink/af_netlink.c:298 [inline]
 __netlink_deliver_tap+0x5be/0xc90 net/netlink/af_netlink.c:325
 netlink_deliver_tap net/netlink/af_netlink.c:338 [inline]
 netlink_deliver_tap_kernel net/netlink/af_netlink.c:347 [inline]
 netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
 netlink_unicast+0x10f1/0x1250 net/netlink/af_netlink.c:1368
 netlink_sendmsg+0x1238/0x13d0 net/netlink/af_netlink.c:1910
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 ____sys_sendmsg+0x9c2/0xd60 net/socket.c:2584
 ___sys_sendmsg+0x28d/0x3c0 net/socket.c:2638
 __sys_sendmsg net/socket.c:2667 [inline]
 __do_sys_sendmsg net/socket.c:2676 [inline]
 __se_sys_sendmsg net/socket.c:2674 [inline]
 __x64_sys_sendmsg+0x307/0x490 net/socket.c:2674
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
 free_pages_prepare mm/page_alloc.c:1087 [inline]
 free_unref_page_prepare+0xb0/0xa40 mm/page_alloc.c:2347
 free_unref_page_list+0xeb/0x1100 mm/page_alloc.c:2533
 release_pages+0x23d3/0x2410 mm/swap.c:1042
 free_pages_and_swap_cache+0xd9/0xf0 mm/swap_state.c:316
 tlb_batch_pages
---truncated---
CVE-2024-26808:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechain
Remove netdevice from inet/ingress basechain in case NETDEV_UNREGISTER
event is reported, otherwise a stale reference to netdevice remains in
the hook list.
CVE-2024-26809:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nft_set_pipapo: release elements in clone only from destroy path
Clone already always provides a current view of the lookup table, use it
to destroy the set, otherwise it is possible to destroy elements twice.
This fix requires:
 212ed75dc5fb (&quot;netfilter: nf_tables: integrate pipapo into commit protocol&quot;)
which came after:
 9827a0e6e23b (&quot;netfilter: nft_set_pipapo: release elements in clone from abort path&quot;).
CVE-2024-26814:In the Linux kernel, the following vulnerability has been resolved:
vfio/fsl-mc: Block calling interrupt handler without trigger
The eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object is
initially NULL and may become NULL if the user sets the trigger
eventfd to -1.  The interrupt handler itself is guaranteed that
trigger is always valid between request_irq() and free_irq(), but
the loopback testing mechanisms to invoke the handler function
need to test the trigger.  The triggering and setting ioctl paths
both make use of igate and are therefore mutually exclusive.
The vfio-fsl-mc driver does not make use of irqfds, nor does it
support any sort of masking operations, therefore unlike vfio-pci
and vfio-platform, the flow can remain essentially unchanged.
CVE-2024-26851:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_conntrack_h323: Add protection for bmp length out of range
UBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shifts
that are out of bounds for their data type.
vmlinux   get_bitmap(b=75) + 712
&lt;net/netfilter/nf_conntrack_h323_asn1.c:0&gt;
vmlinux   decode_seq(bs=0xFFFFFFD008037000, f=0xFFFFFFD008037018, level=134443100) + 1956
&lt;net/netfilter/nf_conntrack_h323_asn1.c:592&gt;
vmlinux   decode_choice(base=0xFFFFFFD0080370F0, level=23843636) + 1216
&lt;net/netfilter/nf_conntrack_h323_asn1.c:814&gt;
vmlinux   decode_seq(f=0xFFFFFFD0080371A8, level=134443500) + 812
&lt;net/netfilter/nf_conntrack_h323_asn1.c:576&gt;
vmlinux   decode_choice(base=0xFFFFFFD008037280, level=0) + 1216
&lt;net/netfilter/nf_conntrack_h323_asn1.c:814&gt;
vmlinux   DecodeRasMessage() + 304
&lt;net/netfilter/nf_conntrack_h323_asn1.c:833&gt;
vmlinux   ras_help() + 684
&lt;net/netfilter/nf_conntrack_h323_main.c:1728&gt;
vmlinux   nf_confirm() + 188
&lt;net/netfilter/nf_conntrack_proto.c:137&gt;
Due to abnormal data in skb-&gt;data, the extension bitmap length
exceeds 32 when decoding ras message then uses the length to make
a shift operation. It will change into negative after several loop.
UBSAN load could detect a negative shift as an undefined behaviour
and reports exception.
So we add the protection to avoid the length exceeding 32. Or else
it will return out of range error and stop decoding.
CVE-2024-26881:In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when 1588 is received on HIP08 devices
The HIP08 devices does not register the ptp devices, so the
hdev-&gt;ptp is NULL, but the hardware can receive 1588 messages,
and set the HNS3_RXD_TS_VLD_B bit, so, if match this case, the
access of hdev-&gt;ptp-&gt;flags will cause a kernel crash:
[ 5888.946472] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
[ 5888.946475] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000018
...
[ 5889.266118] pc : hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
[ 5889.272612] lr : hclge_ptp_get_rx_hwts+0x34/0x170 [hclge]
[ 5889.279101] sp : ffff800012c3bc50
[ 5889.283516] x29: ffff800012c3bc50 x28: ffff2040002be040
[ 5889.289927] x27: ffff800009116484 x26: 0000000080007500
[ 5889.296333] x25: 0000000000000000 x24: ffff204001c6f000
[ 5889.302738] x23: ffff204144f53c00 x22: 0000000000000000
[ 5889.309134] x21: 0000000000000000 x20: ffff204004220080
[ 5889.315520] x19: ffff204144f53c00 x18: 0000000000000000
[ 5889.321897] x17: 0000000000000000 x16: 0000000000000000
[ 5889.328263] x15: 0000004000140ec8 x14: 0000000000000000
[ 5889.334617] x13: 0000000000000000 x12: 00000000010011df
[ 5889.340965] x11: bbfeff4d22000000 x10: 0000000000000000
[ 5889.347303] x9 : ffff800009402124 x8 : 0200f78811dfbb4d
[ 5889.353637] x7 : 2200000000191b01 x6 : ffff208002a7d480
[ 5889.359959] x5 : 0000000000000000 x4 : 0000000000000000
[ 5889.366271] x3 : 0000000000000000 x2 : 0000000000000000
[ 5889.372567] x1 : 0000000000000000 x0 : ffff20400095c080
[ 5889.378857] Call trace:
[ 5889.382285] hclge_ptp_get_rx_hwts+0x40/0x170 [hclge]
[ 5889.388304] hns3_handle_bdinfo+0x324/0x410 [hns3]
[ 5889.394055] hns3_handle_rx_bd+0x60/0x150 [hns3]
[ 5889.399624] hns3_clean_rx_ring+0x84/0x170 [hns3]
[ 5889.405270] hns3_nic_common_poll+0xa8/0x220 [hns3]
[ 5889.411084] napi_poll+0xcc/0x264
[ 5889.415329] net_rx_action+0xd4/0x21c
[ 5889.419911] __do_softirq+0x130/0x358
[ 5889.424484] irq_exit+0x134/0x154
[ 5889.428700] __handle_domain_irq+0x88/0xf0
[ 5889.433684] gic_handle_irq+0x78/0x2c0
[ 5889.438319] el1_irq+0xb8/0x140
[ 5889.442354] arch_cpu_idle+0x18/0x40
[ 5889.446816] default_idle_call+0x5c/0x1c0
[ 5889.451714] cpuidle_idle_call+0x174/0x1b0
[ 5889.456692] do_idle+0xc8/0x160
[ 5889.460717] cpu_startup_entry+0x30/0xfc
[ 5889.465523] secondary_start_kernel+0x158/0x1ec
[ 5889.470936] Code: 97ffab78 f9411c14 91408294 f9457284 (f9400c80)
[ 5889.477950] SMP: stopping secondary CPUs
[ 5890.514626] SMP: failed to stop secondary CPUs 0-69,71-95
[ 5890.522951] Starting crashdump kernel...
CVE-2024-26900:In the Linux kernel, the following vulnerability has been resolved:
md: fix kmemleak of rdev-&gt;serial
If kobject_add() is fail in bind_rdev_to_array(), 'rdev-&gt;serial' will be
alloc not be freed, and kmemleak occurs.
unreferenced object 0xffff88815a350000 (size 49152):
  comm &quot;mdadm&quot;, pid 789, jiffies 4294716910
  hex dump (first 32 bytes):
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace (crc f773277a):
    [&lt;0000000058b0a453&gt;] kmemleak_alloc+0x61/0xe0
    [&lt;00000000366adf14&gt;] __kmalloc_large_node+0x15e/0x270
    [&lt;000000002e82961b&gt;] __kmalloc_node.cold+0x11/0x7f
    [&lt;00000000f206d60a&gt;] kvmalloc_node+0x74/0x150
    [&lt;0000000034bf3363&gt;] rdev_init_serial+0x67/0x170
    [&lt;0000000010e08fe9&gt;] mddev_create_serial_pool+0x62/0x220
    [&lt;00000000c3837bf0&gt;] bind_rdev_to_array+0x2af/0x630
    [&lt;0000000073c28560&gt;] md_add_new_disk+0x400/0x9f0
    [&lt;00000000770e30ff&gt;] md_ioctl+0x15bf/0x1c10
    [&lt;000000006cfab718&gt;] blkdev_ioctl+0x191/0x3f0
    [&lt;0000000085086a11&gt;] vfs_ioctl+0x22/0x60
    [&lt;0000000018b656fe&gt;] __x64_sys_ioctl+0xba/0xe0
    [&lt;00000000e54e675e&gt;] do_syscall_64+0x71/0x150
    [&lt;000000008b0ad622&gt;] entry_SYSCALL_64_after_hwframe+0x6c/0x74
CVE-2024-26901:In the Linux kernel, the following vulnerability has been resolved:
do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleak
syzbot identified a kernel information leak vulnerability in
do_sys_name_to_handle() and issued the following report [1].
[1]
&quot;BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x100 lib/usercopy.c:40
 instrument_copy_to_user include/linux/instrumented.h:114 [inline]
 _copy_to_user+0xbc/0x100 lib/usercopy.c:40
 copy_to_user include/linux/uaccess.h:191 [inline]
 do_sys_name_to_handle fs/fhandle.c:73 [inline]
 __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
 __se_sys_name_to_handle_at+0x949/0xb10 fs/fhandle.c:94
 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
 ...
Uninit was created at:
 slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768
 slab_alloc_node mm/slub.c:3478 [inline]
 __kmem_cache_alloc_node+0x5c9/0x970 mm/slub.c:3517
 __do_kmalloc_node mm/slab_common.c:1006 [inline]
 __kmalloc+0x121/0x3c0 mm/slab_common.c:1020
 kmalloc include/linux/slab.h:604 [inline]
 do_sys_name_to_handle fs/fhandle.c:39 [inline]
 __do_sys_name_to_handle_at fs/fhandle.c:112 [inline]
 __se_sys_name_to_handle_at+0x441/0xb10 fs/fhandle.c:94
 __x64_sys_name_to_handle_at+0xe4/0x140 fs/fhandle.c:94
 ...
Bytes 18-19 of 20 are uninitialized
Memory access of size 20 starts at ffff888128a46380
Data copied to user address 0000000020000240&quot;
Per Chuck Lever's suggestion, use kzalloc() instead of kmalloc() to
solve the problem.
CVE-2024-26903:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_security
During our fuzz testing of the connection and disconnection process at the
RFCOMM layer, we discovered this bug. By comparing the packets from a
normal connection and disconnection process with the testcase that
triggered a KASAN report. We analyzed the cause of this bug as follows:
1. In the packets captured during a normal connection, the host sends a
`Read Encryption Key Size` type of `HCI_CMD` packet
(Command Opcode: 0x1408) to the controller to inquire the length of
encryption key.After receiving this packet, the controller immediately
replies with a Command Completepacket (Event Code: 0x0e) to return the
Encryption Key Size.
2. In our fuzz test case, the timing of the controller's response to this
packet was delayed to an unexpected point: after the RFCOMM and L2CAP
layers had disconnected but before the HCI layer had disconnected.
3. After receiving the Encryption Key Size Response at the time described
in point 2, the host still called the rfcomm_check_security function.
However, by this time `struct l2cap_conn *conn = l2cap_pi(sk)-&gt;chan-&gt;conn;`
had already been released, and when the function executed
`return hci_conn_security(conn-&gt;hcon, d-&gt;sec_level, auth_type, d-&gt;out);`,
specifically when accessing `conn-&gt;hcon`, a null-ptr-deref error occurred.
To fix this bug, check if `sk-&gt;sk_state` is BT_CLOSED before calling
rfcomm_recv_frame in rfcomm_process_rx.
CVE-2024-26907:In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Fix fortify source warning while accessing Eth segment
 ------------[ cut here ]------------
 memcpy: detected field-spanning write (size 56) of single field &quot;eseg-&gt;inline_hdr.start&quot; at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2)
 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]
 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
  [last unloaded: mlx_compat(OE)]
 CPU: 0 PID: 293779 Comm: ssh Tainted: G           OE      6.2.0-32-generic #32~22.04.1-Ubuntu
 Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
 RIP: 0010:mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
 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
 RSP: 0018:ffffb5b48478b570 EFLAGS: 00010046
 RAX: 0000000000000000 RBX: 0000000000000001 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
 RBP: ffffb5b48478b628 R08: 0000000000000000 R09: 0000000000000000
 R10: 0000000000000000 R11: 0000000000000000 R12: ffffb5b48478b5e8
 R13: ffff963a3c609b5e R14: ffff9639c3fbd800 R15: ffffb5b480475a80
 FS:  00007fc03b444c80(0000) GS:ffff963a3dc00000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
 CR2: 0000556f46bdf000 CR3: 0000000006ac6003 CR4: 00000000003706f0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
 Call Trace:
  &lt;TASK&gt;
  ? show_regs+0x72/0x90
  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
  ? __warn+0x8d/0x160
  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
  ? report_bug+0x1bb/0x1d0
  ? handle_bug+0x46/0x90
  ? exc_invalid_op+0x19/0x80
  ? asm_exc_invalid_op+0x1b/0x20
  ? mlx5_ib_post_send+0x191b/0x1a60 [mlx5_ib]
  mlx5_ib_post_send_nodrain+0xb/0x20 [mlx5_ib]
  ipoib_send+0x2ec/0x770 [ib_ipoib]
  ipoib_start_xmit+0x5a0/0x770 [ib_ipoib]
  dev_hard_start_xmit+0x8e/0x1e0
  ? validate_xmit_skb_list+0x4d/0x80
  sch_direct_xmit+0x116/0x3a0
  __dev_xmit_skb+0x1fd/0x580
  __dev_queue_xmit+0x284/0x6b0
  ? _raw_spin_unlock_irq+0xe/0x50
  ? __flush_work.isra.0+0x20d/0x370
  ? push_pseudo_header+0x17/0x40 [ib_ipoib]
  neigh_connected_output+0xcd/0x110
  ip_finish_output2+0x179/0x480
  ? __smp_call_single_queue+0x61/0xa0
  __ip_finish_output+0xc3/0x190
  ip_finish_output+0x2e/0xf0
  ip_output+0x78/0x110
  ? __pfx_ip_finish_output+0x10/0x10
  ip_local_out+0x64/0x70
  __ip_queue_xmit+0x18a/0x460
  ip_queue_xmit+0x15/0x30
  __tcp_transmit_skb+0x914/0x9c0
  tcp_write_xmit+0x334/0x8d0
  tcp_push_one+0x3c/0x60
  tcp_sendmsg_locked+0x2e1/0xac0
  tcp_sendmsg+0x2d/0x50
  inet_sendmsg+0x43/0x90
  sock_sendmsg+0x68/0x80
  sock_write_iter+0x93/0x100
  vfs_write+0x326/0x3c0
  ksys_write+0xbd/0xf0
  ? do_syscall_64+0x69/0x90
  __x64_sys_write+0x19/0x30
  do_syscall_
---truncated---
CVE-2024-26908:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-26923:In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix garbage collector racing against connect()
Garbage collector does not take into account the risk of embryo getting
enqueued during the garbage collection. If such embryo has a peer that
carries SCM_RIGHTS, two consecutive passes of scan_children() may see a
different set of children. Leading to an incorrectly elevated inflight
count, and then a dangling pointer within the gc_inflight_list.
sockets are AF_UNIX/SOCK_STREAM
S is an unconnected socket
L is a listening in-flight socket bound to addr, not in fdtable
V's fd will be passed via sendmsg(), gets inflight count bumped
connect(S, addr)	sendmsg(S, [V]); close(V)	__unix_gc()
----------------	-------------------------	-----------
NS = unix_create1()
skb1 = sock_wmalloc(NS)
L = unix_find_other(addr)
unix_state_lock(L)
unix_peer(S) = NS
			// V count=1 inflight=0
 			NS = unix_peer(S)
 			skb2 = sock_alloc()
			skb_queue_tail(NS, skb2[V])
			// V became in-flight
			// V count=2 inflight=1
			close(V)
			// V count=1 inflight=1
			// GC candidate condition met
						for u in gc_inflight_list:
						  if (total_refs == inflight_refs)
						    add u to gc_candidates
						// gc_candidates={L, V}
						for u in gc_candidates:
						  scan_children(u, dec_inflight)
						// embryo (skb1) was not
						// reachable from L yet, so V's
						// inflight remains unchanged
__skb_queue_tail(L, skb1)
unix_state_unlock(L)
						for u in gc_candidates:
						  if (u.inflight)
						    scan_children(u, inc_inflight_move_tail)
						// V count=1 inflight=2 (!)
If there is a GC-candidate listening socket, lock/unlock its state. This
makes GC wait until the end of any ongoing connect() to that socket. After
flipping the lock, a possibly SCM-laden embryo is already enqueued. And if
there is another embryo coming, it can not possibly carry SCM_RIGHTS. At
this point, unix_inflight() can not happen because unix_gc_lock is already
taken. Inflight graph remains unaffected.
CVE-2024-26937:In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Reset queue_priority_hint on parking
Originally, with strict in order execution, we could complete execution
only when the queue was empty. Preempt-to-busy allows replacement of an
active request that may complete before the preemption is processed by
HW. If that happens, the request is retired from the queue, but the
queue_priority_hint remains set, preventing direct submission until
after the next CS interrupt is processed.
This preempt-to-busy race can be triggered by the heartbeat, which will
also act as the power-management barrier and upon completion allow us to
idle the HW. We may process the completion of the heartbeat, and begin
parking the engine before the CS event that restores the
queue_priority_hint, causing us to fail the assertion that it is MIN.
&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))
&lt;0&gt;[  166.210781] Dumping ftrace buffer:
&lt;0&gt;[  166.210795] ---------------------------------
...
&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 }
&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
&lt;0&gt;[  167.302928] drm_fdin-1097      2d.s2. 165741072us : __i915_request_unsubmit: 0000:00:02.0 rcs0: fence 1217:2, current 0
&lt;0&gt;[  167.302992] drm_fdin-1097      2d.s2. 165741073us : __i915_request_submit: 0000:00:02.0 rcs0: fence 3:4660, current 4659
&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
&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 }
&lt;0&gt;[  167.303159] kworker/-89       11..... 165741139us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence c90:2, current 2
&lt;0&gt;[  167.303208] kworker/-89       11..... 165741148us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:c90 unpin
&lt;0&gt;[  167.303272] kworker/-89       11..... 165741159us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 1217:2, current 2
&lt;0&gt;[  167.303321] kworker/-89       11..... 165741166us : __intel_context_do_unpin: 0000:00:02.0 rcs0: context:1217 unpin
&lt;0&gt;[  167.303384] kworker/-89       11..... 165741170us : i915_request_retire.part.0: 0000:00:02.0 rcs0: fence 3:4660, current 4660
&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 }
&lt;0&gt;[  167.303484] kworker/-89       11..... 165741198us : __engine_park: 0000:00:02.0 rcs0: parked
&lt;0&gt;[  167.303534]   &lt;idle&gt;-0         5d.H3. 165741207us : execlists_irq_handler: 0000:00:02.0 rcs0: semaphore yield: 00000040
&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 }
&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 }
&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))
&lt;0&gt;[  167.303811] ---------------------------------
&lt;4&gt;[  167.304722] ------------[ cut here ]------------
&lt;2&gt;[  167.304725] kernel BUG at drivers/gpu/drm/i915/gt/intel_engine_pm.c:283!
&lt;4&gt;[  167.304731] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
&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
&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
&lt;4&gt;[  167.304738] Workqueue: i915-unordered retire_work_handler [i915]
&lt;4&gt;[  16
---truncated---
CVE-2024-26970:In the Linux kernel, the following vulnerability has been resolved:
clk: qcom: gcc-ipq6018: fix terminating of frequency table arrays
The frequency table arrays are supposed to be terminated with an
empty element. Add such entry to the end of the arrays where it
is missing in order to avoid possible out-of-bound access when
the table is traversed by functions like qcom_find_freq() or
qcom_find_freq_floor().
Only compile tested.
CVE-2024-26976:In the Linux kernel, the following vulnerability has been resolved:
KVM: Always flush async #PF workqueue when vCPU is being destroyed
Always flush the per-vCPU async #PF workqueue when a vCPU is clearing its
completion queue, e.g. when a VM and all its vCPUs is being destroyed.
KVM must ensure that none of its workqueue callbacks is running when the
last reference to the KVM _module_ is put.  Gifting a reference to the
associated VM prevents the workqueue callback from dereferencing freed
vCPU/VM memory, but does not prevent the KVM module from being unloaded
before the callback completes.
Drop the misguided VM refcount gifting, as calling kvm_put_kvm() from
async_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue will
result in deadlock.  async_pf_execute() can't return until kvm_put_kvm()
finishes, and kvm_put_kvm() can't return until async_pf_execute() finishes:
 WARNING: CPU: 8 PID: 251 at virt/kvm/kvm_main.c:1435 kvm_put_kvm+0x2d/0x320 [kvm]
 Modules linked in: vhost_net vhost vhost_iotlb tap kvm_intel kvm irqbypass
 CPU: 8 PID: 251 Comm: kworker/8:1 Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 0.0.0 02/06/2015
 Workqueue: events async_pf_execute [kvm]
 RIP: 0010:kvm_put_kvm+0x2d/0x320 [kvm]
 Call Trace:
  &lt;TASK&gt;
  async_pf_execute+0x198/0x260 [kvm]
  process_one_work+0x145/0x2d0
  worker_thread+0x27e/0x3a0
  kthread+0xba/0xe0
  ret_from_fork+0x2d/0x50
  ret_from_fork_asm+0x11/0x20
  &lt;/TASK&gt;
 ---[ end trace 0000000000000000 ]---
 INFO: task kworker/8:1:251 blocked for more than 120 seconds.
       Tainted: G        W          6.6.0-rc1-e7af8d17224a-x86/gmem-vm #119
 &quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
 task:kworker/8:1     state:D stack:0     pid:251   ppid:2      flags:0x00004000
 Workqueue: events async_pf_execute [kvm]
 Call Trace:
  &lt;TASK&gt;
  __schedule+0x33f/0xa40
  schedule+0x53/0xc0
  schedule_timeout+0x12a/0x140
  __wait_for_common+0x8d/0x1d0
  __flush_work.isra.0+0x19f/0x2c0
  kvm_clear_async_pf_completion_queue+0x129/0x190 [kvm]
  kvm_arch_destroy_vm+0x78/0x1b0 [kvm]
  kvm_put_kvm+0x1c1/0x320 [kvm]
  async_pf_execute+0x198/0x260 [kvm]
  process_one_work+0x145/0x2d0
  worker_thread+0x27e/0x3a0
  kthread+0xba/0xe0
  ret_from_fork+0x2d/0x50
  ret_from_fork_asm+0x11/0x20
  &lt;/TASK&gt;
If kvm_clear_async_pf_completion_queue() actually flushes the workqueue,
then there's no need to gift async_pf_execute() a reference because all
invocations of async_pf_execute() will be forced to complete before the
vCPU and its VM are destroyed/freed.  And that in turn fixes the module
unloading bug as __fput() won't do module_put() on the last vCPU reference
until the vCPU has been freed, e.g. if closing the vCPU file also puts the
last reference to the KVM module.
Note that kvm_check_async_pf_completion() may also take the work item off
the completion queue and so also needs to flush the work queue, as the
work will not be seen by kvm_clear_async_pf_completion_queue().  Waiting
on the workqueue could theoretically delay a vCPU due to waiting for the
work to complete, but that's a very, very small chance, and likely a very
small delay.  kvm_arch_async_page_present_queued() unconditionally makes a
new request, i.e. will effectively delay entering the guest, so the
remaining work is really just:
        trace_kvm_async_pf_completed(addr, cr2_or_gpa);
        __kvm_vcpu_wake_up(vcpu);
        mmput(mm);
and mmput() can't drop the last reference to the page tables if the vCPU is
still alive, i.e. the vCPU won't get stuck tearing down page tables.
Add a helper to do the flushing, specifically to deal with &quot;wakeup all&quot;
work items, as they aren't actually work items, i.e. are never placed in a
workqueue.  Trying to flush a bogus workqueue entry rightly makes
__flush_work() complain (kudos to whoever added that sanity check).
Note, commit 5f6de5cbebee (&quot;KVM: Prevent module exit until al
---truncated---
CVE-2024-26982:In the Linux kernel, the following vulnerability has been resolved:
Squashfs: check the inode number is not the invalid value of zero
Syskiller has produced an out of bounds access in fill_meta_index().
That out of bounds access is ultimately caused because the inode
has an inode number with the invalid value of zero, which was not checked.
The reason this causes the out of bounds access is due to following
sequence of events:
1. Fill_meta_index() is called to allocate (via empty_meta_index())
   and fill a metadata index.  It however suffers a data read error
   and aborts, invalidating the newly returned empty metadata index.
   It does this by setting the inode number of the index to zero,
   which means unused (zero is not a valid inode number).
2. When fill_meta_index() is subsequently called again on another
   read operation, locate_meta_index() returns the previous index
   because it matches the inode number of 0.  Because this index
   has been returned it is expected to have been filled, and because
   it hasn't been, an out of bounds access is performed.
This patch adds a sanity check which checks that the inode number
is not zero when the inode is created and returns -EINVAL if it is.
[phillip@squashfs.org.uk: whitespace fix]
  Link: https://lkml.kernel.org/r/20240409204723.446925-1-phillip@squashfs.org.uk
CVE-2024-27002:In the Linux kernel, the following vulnerability has been resolved:
clk: mediatek: Do a runtime PM get on controllers during probe
mt8183-mfgcfg has a mutual dependency with genpd during the probing
stage, which leads to a deadlock in the following call stack:
CPU0:  genpd_lock --&gt; clk_prepare_lock
genpd_power_off_work_fn()
 genpd_lock()
 generic_pm_domain::power_off()
    clk_unprepare()
      clk_prepare_lock()
CPU1: clk_prepare_lock --&gt; genpd_lock
clk_register()
  __clk_core_init()
    clk_prepare_lock()
    clk_pm_runtime_get()
      genpd_lock()
Do a runtime PM get at the probe function to make sure clk_register()
won't acquire the genpd lock. Instead of only modifying mt8183-mfgcfg,
do this on all mediatek clock controller probings because we don't
believe this would cause any regression.
Verified on MT8183 and MT8192 Chromebooks.
CVE-2024-27072:In the Linux kernel, the following vulnerability has been resolved:
media: usbtv: Remove useless locks in usbtv_video_free()
Remove locks calls in usbtv_video_free() because
are useless and may led to a deadlock as reported here:
https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000
Also remove usbtv_stop() call since it will be called when
unregistering the device.
Before 'c838530d230b' this issue would only be noticed if you
disconnect while streaming and now it is noticeable even when
disconnecting while not streaming.
[hverkuil: fix minor spelling mistake in log message]
CVE-2024-27395:In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: Fix Use-After-Free in ovs_ct_exit
Since kfree_rcu, which is called in the hlist_for_each_entry_rcu traversal
of ovs_ct_limit_exit, is not part of the RCU read critical section, it
is possible that the RCU grace period will pass during the traversal and
the key will be free.
To prevent this, it should be changed to hlist_for_each_entry_safe.
CVE-2024-27396:In the Linux kernel, the following vulnerability has been resolved:
net: gtp: Fix Use-After-Free in gtp_dellink
Since call_rcu, which is called in the hlist_for_each_entry_rcu traversal
of gtp_dellink, is not part of the RCU read critical section, it
is possible that the RCU grace period will pass during the traversal and
the key will be free.
To prevent this, it should be changed to hlist_for_each_entry_safe.
CVE-2024-27398:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: Fix use-after-free bugs caused by sco_sock_timeout
When the sco connection is established and then, the sco socket
is releasing, timeout_work will be scheduled to judge whether
the sco disconnection is timeout. The sock will be deallocated
later, but it is dereferenced again in sco_sock_timeout. As a
result, the use-after-free bugs will happen. The root cause is
shown below:
    Cleanup Thread               |      Worker Thread
sco_sock_release                 |
  sco_sock_close                 |
    __sco_sock_close             |
      sco_sock_set_timer         |
        schedule_delayed_work    |
  sco_sock_kill                  |    (wait a time)
    sock_put(sk) //FREE          |  sco_sock_timeout
                                 |    sock_hold(sk) //USE
The KASAN report triggered by POC is shown below:
[   95.890016] ==================================================================
[   95.890496] BUG: KASAN: slab-use-after-free in sco_sock_timeout+0x5e/0x1c0
[   95.890755] Write of size 4 at addr ffff88800c388080 by task kworker/0:0/7
...
[   95.890755] Workqueue: events sco_sock_timeout
[   95.890755] Call Trace:
[   95.890755]  &lt;TASK&gt;
[   95.890755]  dump_stack_lvl+0x45/0x110
[   95.890755]  print_address_description+0x78/0x390
[   95.890755]  print_report+0x11b/0x250
[   95.890755]  ? __virt_addr_valid+0xbe/0xf0
[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0
[   95.890755]  kasan_report+0x139/0x170
[   95.890755]  ? update_load_avg+0xe5/0x9f0
[   95.890755]  ? sco_sock_timeout+0x5e/0x1c0
[   95.890755]  kasan_check_range+0x2c3/0x2e0
[   95.890755]  sco_sock_timeout+0x5e/0x1c0
[   95.890755]  process_one_work+0x561/0xc50
[   95.890755]  worker_thread+0xab2/0x13c0
[   95.890755]  ? pr_cont_work+0x490/0x490
[   95.890755]  kthread+0x279/0x300
[   95.890755]  ? pr_cont_work+0x490/0x490
[   95.890755]  ? kthread_blkcg+0xa0/0xa0
[   95.890755]  ret_from_fork+0x34/0x60
[   95.890755]  ? kthread_blkcg+0xa0/0xa0
[   95.890755]  ret_from_fork_asm+0x11/0x20
[   95.890755]  &lt;/TASK&gt;
[   95.890755]
[   95.890755] Allocated by task 506:
[   95.890755]  kasan_save_track+0x3f/0x70
[   95.890755]  __kasan_kmalloc+0x86/0x90
[   95.890755]  __kmalloc+0x17f/0x360
[   95.890755]  sk_prot_alloc+0xe1/0x1a0
[   95.890755]  sk_alloc+0x31/0x4e0
[   95.890755]  bt_sock_alloc+0x2b/0x2a0
[   95.890755]  sco_sock_create+0xad/0x320
[   95.890755]  bt_sock_create+0x145/0x320
[   95.890755]  __sock_create+0x2e1/0x650
[   95.890755]  __sys_socket+0xd0/0x280
[   95.890755]  __x64_sys_socket+0x75/0x80
[   95.890755]  do_syscall_64+0xc4/0x1b0
[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
[   95.890755]
[   95.890755] Freed by task 506:
[   95.890755]  kasan_save_track+0x3f/0x70
[   95.890755]  kasan_save_free_info+0x40/0x50
[   95.890755]  poison_slab_object+0x118/0x180
[   95.890755]  __kasan_slab_free+0x12/0x30
[   95.890755]  kfree+0xb2/0x240
[   95.890755]  __sk_destruct+0x317/0x410
[   95.890755]  sco_sock_release+0x232/0x280
[   95.890755]  sock_close+0xb2/0x210
[   95.890755]  __fput+0x37f/0x770
[   95.890755]  task_work_run+0x1ae/0x210
[   95.890755]  get_signal+0xe17/0xf70
[   95.890755]  arch_do_signal_or_restart+0x3f/0x520
[   95.890755]  syscall_exit_to_user_mode+0x55/0x120
[   95.890755]  do_syscall_64+0xd1/0x1b0
[   95.890755]  entry_SYSCALL_64_after_hwframe+0x67/0x6f
[   95.890755]
[   95.890755] The buggy address belongs to the object at ffff88800c388000
[   95.890755]  which belongs to the cache kmalloc-1k of size 1024
[   95.890755] The buggy address is located 128 bytes inside of
[   95.890755]  freed 1024-byte region [ffff88800c388000, ffff88800c388400)
[   95.890755]
[   95.890755] The buggy address belongs to the physical page:
[   95.890755] page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88800c38a800 pfn:0xc388
[   95.890755] head: order:3 entire_mapcount:0 nr_pages_mapped:0 pincount:0
[   95.890755] ano
---truncated---
CVE-2024-27401:In the Linux kernel, the following vulnerability has been resolved:
firewire: nosy: ensure user_length is taken into account when fetching packet contents
Ensure that packet_buffer_get respects the user_length provided. If
the length of the head packet exceeds the user_length, packet_buffer_get
will now return 0 to signify to the user that no data were read
and a larger buffer size is required. Helps prevent user space overflows.
CVE-2024-27407:In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Fixed overflow check in mi_enum_attr()
CVE-2024-27419:In the Linux kernel, the following vulnerability has been resolved:
netrom: Fix data-races around sysctl_net_busy_read
We need to protect the reader reading the sysctl value because the
value can be changed concurrently.
CVE-2024-27426:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-27427:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-27431:In the Linux kernel, the following vulnerability has been resolved:
cpumap: Zero-initialise xdp_rxq_info struct before running XDP program
When running an XDP program that is attached to a cpumap entry, we don't
initialise the xdp_rxq_info data structure being used in the xdp_buff
that backs the XDP program invocation. Tobias noticed that this leads to
random values being returned as the xdp_md-&gt;rx_queue_index value for XDP
programs running in a cpumap.
This means we're basically returning the contents of the uninitialised
memory, which is bad. Fix this by zero-initialising the rxq data
structure before running the XDP program.
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.
CVE-2024-35791:In the Linux kernel, the following vulnerability has been resolved:
KVM: SVM: Flush pages under kvm-&gt;lock to fix UAF in svm_register_enc_region()
Do the cache flush of converted pages in svm_register_enc_region() before
dropping kvm-&gt;lock to fix use-after-free issues where region and/or its
array of pages could be freed by a different task, e.g. if userspace has
__unregister_enc_region_locked() already queued up for the region.
Note, the &quot;obvious&quot; alternative of using local variables doesn't fully
resolve the bug, as region-&gt;pages is also dynamically allocated.  I.e. the
region structure itself would be fine, but region-&gt;pages could be freed.
Flushing multiple pages under kvm-&gt;lock is unfortunate, but the entire
flow is a rare slow path, and the manual flush is only needed on CPUs that
lack coherency for encrypted memory.
CVE-2024-35801:In the Linux kernel, the following vulnerability has been resolved:
x86/fpu: Keep xfd_state in sync with MSR_IA32_XFD
Commit 672365477ae8 (&quot;x86/fpu: Update XFD state where required&quot;) and
commit 8bf26758ca96 (&quot;x86/fpu: Add XFD state to fpstate&quot;) introduced a
per CPU variable xfd_state to keep the MSR_IA32_XFD value cached, in
order to avoid unnecessary writes to the MSR.
On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, which
wipes out any stale state. But the per CPU cached xfd value is not
reset, which brings them out of sync.
As a consequence a subsequent xfd_update_state() might fail to update
the MSR which in turn can result in XRSTOR raising a #NM in kernel
space, which crashes the kernel.
To fix this, introduce xfd_set_state() to write xfd_state together
with MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.
CVE-2024-35805:In the Linux kernel, the following vulnerability has been resolved:
dm snapshot: fix lockup in dm_exception_table_exit
There was reported lockup when we exit a snapshot with many exceptions.
Fix this by adding &quot;cond_resched&quot; to the loop that frees the exceptions.
CVE-2024-35806:In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Always disable interrupts when taking cgr_lock
smp_call_function_single disables IRQs when executing the callback. To
prevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.
This is already done by qman_update_cgr and qman_delete_cgr; fix the
other lockers.
CVE-2024-35807:In the Linux kernel, the following vulnerability has been resolved:
ext4: fix corruption during on-line resize
We observed a corruption during on-line resize of a file system that is
larger than 16 TiB with 4k block size. With having more then 2^32 blocks
resize_inode is turned off by default by mke2fs. The issue can be
reproduced on a smaller file system for convenience by explicitly
turning off resize_inode. An on-line resize across an 8 GiB boundary (the
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
  mkdir -p /corruption
  /sbin/mke2fs -t ext4 -b 4096 -O ^resize_inode $dev $((2 * 2**21 - 2**15))
  mount -t ext4 $dev /corruption
  dd if=/dev/zero bs=4096 of=/corruption/test count=$((2*2**21 - 4*2**15))
  sha1sum /corruption/test
  # 79d2658b39dcfd77274e435b0934028adafaab11  /corruption/test
  /sbin/resize2fs $dev $((2*2**21))
  # drop page cache to force reload the block from disk
  echo 1 &gt; /proc/sys/vm/drop_caches
  sha1sum /corruption/test
  # 3c2abc63cbf1a94c9e6977e0fbd72cd832c4d5c3  /corruption/test
2^21 = 2^15*2^6 equals 8 GiB whereof 2^15 is the number of blocks per
block group and 2^6 are the number of block groups that make a meta
block group.
The last checksum might be different depending on how the file is laid
out across the physical blocks. The actual corruption occurs at physical
block 63*2^15 = 2064384 which would be the location of the backup of the
meta block group's block descriptor. During the on-line resize the file
system will be converted to meta_bg starting at s_first_meta_bg which is
2 in the example - meaning all block groups after 16 GiB. However, in
ext4_flex_group_add we might add block groups that are not part of the
first meta block group yet. In the reproducer we achieved this by
substracting the size of a whole block group from the point where the
meta block group would start. This must be considered when updating the
backup block group descriptors to follow the non-meta_bg layout. The fix
is to add a test whether the group to add is already part of the meta
block group or not.
CVE-2024-35818:In the Linux kernel, the following vulnerability has been resolved:
LoongArch: Define the __io_aw() hook as mmiowb()
Commit fb24ea52f78e0d595852e (&quot;drivers: Remove explicit invocations of
mmiowb()&quot;) remove all mmiowb() in drivers, but it says:
&quot;NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
spin_unlock(). However, pairing each mmiowb() removal in this patch with
the corresponding call to spin_unlock() is not at all trivial, so there
is a small chance that this change may regress any drivers incorrectly
relying on mmiowb() to order MMIO writes between CPUs using lock-free
synchronisation.&quot;
The mmio in radeon_ring_commit() is protected by a mutex rather than a
spinlock, but in the mutex fastpath it behaves similar to spinlock. We
can add mmiowb() calls in the radeon driver but the maintainer says he
doesn't like such a workaround, and radeon is not the only example of
mutex protected mmio.
So we should extend the mmiowb tracking system from spinlock to mutex,
and maybe other locking primitives. This is not easy and error prone, so
we solve it in the architectural code, by simply defining the __io_aw()
hook as mmiowb(). And we no longer need to override queued_spin_unlock()
so use the generic definition.
Without this, we get such an error when run 'glxgears' on weak ordering
architectures such as LoongArch:
radeon 0000:04:00.0: ring 0 stalled for more than 10324msec
radeon 0000:04:00.0: ring 3 stalled for more than 10240msec
radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000001f412 last fence id 0x000000000001f414 on ring 3)
radeon 0000:04:00.0: GPU lockup (current fence id 0x000000000000f940 last fence id 0x000000000000f941 on ring 0)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
radeon 0000:04:00.0: scheduling IB failed (-35).
[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn't update BO_VA (-35)
CVE-2024-35835:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: fix a double-free in arfs_create_groups
When `in` allocated by kvzalloc fails, arfs_create_groups will free
ft-&gt;g and return an error. However, arfs_create_table, the only caller of
arfs_create_groups, will hold this error and call to
mlx5e_destroy_flow_table, in which the ft-&gt;g will be freed again.
CVE-2024-35844:In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix reserve_cblocks counting error when out of space
When a file only needs one direct_node, performing the following
operations will cause the file to be unrepairable:
unisoc # ./f2fs_io compress test.apk
unisoc #df -h | grep dm-48
/dev/block/dm-48 112G 112G 1.2M 100% /data
unisoc # ./f2fs_io release_cblocks test.apk
924
unisoc # df -h | grep dm-48
/dev/block/dm-48 112G 112G 4.8M 100% /data
unisoc # dd if=/dev/random of=file4 bs=1M count=3
3145728 bytes (3.0 M) copied, 0.025 s, 120 M/s
unisoc # df -h | grep dm-48
/dev/block/dm-48 112G 112G 1.8M 100% /data
unisoc # ./f2fs_io reserve_cblocks test.apk
F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
adb reboot
unisoc # df -h  | grep dm-48
/dev/block/dm-48             112G 112G   11M 100% /data
unisoc # ./f2fs_io reserve_cblocks test.apk
0
This is because the file has only one direct_node. After returning
to -ENOSPC, reserved_blocks += ret will not be executed. As a result,
the reserved_blocks at this time is still 0, which is not the real
number of reserved blocks. Therefore, fsck cannot be set to repair
the file.
After this patch, the fsck flag will be set to fix this problem.
unisoc # df -h | grep dm-48
/dev/block/dm-48             112G 112G  1.8M 100% /data
unisoc # ./f2fs_io reserve_cblocks test.apk
F2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on device
adb reboot then fsck will be executed
unisoc # df -h  | grep dm-48
/dev/block/dm-48             112G 112G   11M 100% /data
unisoc # ./f2fs_io reserve_cblocks test.apk
924
CVE-2024-35845:In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: dbg-tlv: ensure NUL termination
The iwl_fw_ini_debug_info_tlv is used as a string, so we must
ensure the string is terminated correctly before using it.
CVE-2024-35848:In the Linux kernel, the following vulnerability has been resolved:
eeprom: at24: fix memory corruption race condition
If the eeprom is not accessible, an nvmem device will be registered, the
read will fail, and the device will be torn down. If another driver
accesses the nvmem device after the teardown, it will reference
invalid memory.
Move the failure point before registering the nvmem device.
CVE-2024-35849:In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix information leak in btrfs_ioctl_logical_to_ino()
Syzbot reported the following information leak for in
btrfs_ioctl_logical_to_ino():
  BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
  BUG: KMSAN: kernel-infoleak in _copy_to_user+0xbc/0x110 lib/usercopy.c:40
   instrument_copy_to_user include/linux/instrumented.h:114 [inline]
   _copy_to_user+0xbc/0x110 lib/usercopy.c:40
   copy_to_user include/linux/uaccess.h:191 [inline]
   btrfs_ioctl_logical_to_ino+0x440/0x750 fs/btrfs/ioctl.c:3499
   btrfs_ioctl+0x714/0x1260
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:904 [inline]
   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  Uninit was created at:
   __kmalloc_large_node+0x231/0x370 mm/slub.c:3921
   __do_kmalloc_node mm/slub.c:3954 [inline]
   __kmalloc_node+0xb07/0x1060 mm/slub.c:3973
   kmalloc_node include/linux/slab.h:648 [inline]
   kvmalloc_node+0xc0/0x2d0 mm/util.c:634
   kvmalloc include/linux/slab.h:766 [inline]
   init_data_container+0x49/0x1e0 fs/btrfs/backref.c:2779
   btrfs_ioctl_logical_to_ino+0x17c/0x750 fs/btrfs/ioctl.c:3480
   btrfs_ioctl+0x714/0x1260
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:904 [inline]
   __se_sys_ioctl+0x261/0x450 fs/ioctl.c:890
   __x64_sys_ioctl+0x96/0xe0 fs/ioctl.c:890
   x64_sys_call+0x1883/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:17
   do_syscall_x64 arch/x86/entry/common.c:52 [inline]
   do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  Bytes 40-65535 of 65536 are uninitialized
  Memory access of size 65536 starts at ffff888045a40000
This happens, because we're copying a 'struct btrfs_data_container' back
to user-space. This btrfs_data_container is allocated in
'init_data_container()' via kvmalloc(), which does not zero-fill the
memory.
Fix this by using kvzalloc() which zeroes out the memory on allocation.
CVE-2024-35898:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: Fix potential data-race in __nft_flowtable_type_get()
nft_unregister_flowtable_type() within nf_flow_inet_module_exit() can
concurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().
And thhere is not any protection when iterate over nf_tables_flowtables
list in __nft_flowtable_type_get(). Therefore, there is pertential
data-race of nf_tables_flowtables list entry.
Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables list
in __nft_flowtable_type_get(), and use rcu_read_lock() in the caller
nft_flowtable_type_get() to protect the entire type query process.
CVE-2024-35922:In the Linux kernel, the following vulnerability has been resolved:
fbmon: prevent division by zero in fb_videomode_from_videomode()
The expression htotal * vtotal can have a zero value on
overflow. It is necessary to prevent division by zero like in
fb_var_to_videomode().
Found by Linux Verification Center (linuxtesting.org) with Svace.
CVE-2024-35934:In the Linux kernel, the following vulnerability has been resolved:
net/smc: reduce rtnl pressure in smc_pnet_create_pnetids_list()
Many syzbot reports show extreme rtnl pressure, and many of them hint
that smc acquires rtnl in netns creation for no good reason [1]
This patch returns early from smc_pnet_net_init()
if there is no netdevice yet.
I am not even sure why smc_pnet_create_pnetids_list() even exists,
because smc_pnet_netdev_event() is also calling
smc_pnet_add_base_pnetid() when handling NETDEV_UP event.
[1] extract of typical syzbot reports
2 locks held by syz-executor.3/12252:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
2 locks held by syz-executor.4/12253:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
2 locks held by syz-executor.1/12257:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
2 locks held by syz-executor.2/12261:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
2 locks held by syz-executor.0/12265:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
2 locks held by syz-executor.3/12268:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
2 locks held by syz-executor.4/12271:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
2 locks held by syz-executor.1/12274:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
2 locks held by syz-executor.2/12280:
  #0: ffffffff8f369610 (pernet_ops_rwsem){++++}-{3:3}, at: copy_net_ns+0x4c7/0x7b0 net/core/net_namespace.c:491
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_create_pnetids_list net/smc/smc_pnet.c:809 [inline]
  #1: ffffffff8f375b88 (rtnl_mutex){+.+.}-{3:3}, at: smc_pnet_net_init+0x10a/0x1e0 net/smc/smc_pnet.c:878
CVE-2024-35936:In the Linux kernel, the following vulnerability has been resolved:
btrfs: handle chunk tree lookup error in btrfs_relocate_sys_chunks()
The unhandled case in btrfs_relocate_sys_chunks() loop is a corruption,
as it could be caused only by two impossible conditions:
- at first the search key is set up to look for a chunk tree item, with
  offset -1, this is an inexact search and the key-&gt;offset will contain
  the correct offset upon a successful search, a valid chunk tree item
  cannot have an offset -1
- after first successful search, the found_key corresponds to a chunk
  item, the offset is decremented by 1 before the next loop, it's
  impossible to find a chunk item there due to alignment and size
  constraints
CVE-2024-35938:In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: decrease MHI channel buffer length to 8KB
Currently buf_len field of ath11k_mhi_config_qca6390 is assigned
with 0, making MHI use a default size, 64KB, to allocate channel
buffers. This is likely to fail in some scenarios where system
memory is highly fragmented and memory compaction or reclaim is
not allowed.
There is a fail report which is caused by it:
kworker/u32:45: page allocation failure: order:4, mode:0x40c00(GFP_NOIO|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
CPU: 0 PID: 19318 Comm: kworker/u32:45 Not tainted 6.8.0-rc3-1.gae4495f-default #1 openSUSE Tumbleweed (unreleased) 493b6d5b382c603654d7a81fc3c144d59a1dfceb
Workqueue: events_unbound async_run_entry_fn
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x47/0x60
 warn_alloc+0x13a/0x1b0
 ? srso_alias_return_thunk+0x5/0xfbef5
 ? __alloc_pages_direct_compact+0xab/0x210
 __alloc_pages_slowpath.constprop.0+0xd3e/0xda0
 __alloc_pages+0x32d/0x350
 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 __kmalloc_large_node+0x72/0x110
 __kmalloc+0x37c/0x480
 ? mhi_map_single_no_bb+0x77/0xf0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 ? mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 mhi_prepare_channel+0x127/0x2d0 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 __mhi_prepare_for_transfer+0x44/0x80 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 ? __pfx_____mhi_prepare_for_transfer+0x10/0x10 [mhi 40df44e07c05479f7a6e7b90fba9f0e0031a7814]
 device_for_each_child+0x5c/0xa0
 ? __pfx_pci_pm_resume+0x10/0x10
 ath11k_core_resume+0x65/0x100 [ath11k a5094e22d7223135c40d93c8f5321cf09fd85e4e]
 ? srso_alias_return_thunk+0x5/0xfbef5
 ath11k_pci_pm_resume+0x32/0x60 [ath11k_pci 830b7bfc3ea80ebef32e563cafe2cb55e9cc73ec]
 ? srso_alias_return_thunk+0x5/0xfbef5
 dpm_run_callback+0x8c/0x1e0
 device_resume+0x104/0x340
 ? __pfx_dpm_watchdog_handler+0x10/0x10
 async_resume+0x1d/0x30
 async_run_entry_fn+0x32/0x120
 process_one_work+0x168/0x330
 worker_thread+0x2f5/0x410
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe8/0x120
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1b/0x30
 &lt;/TASK&gt;
Actually those buffers are used only by QMI target -&gt; host communication.
And for WCN6855 and QCA6390, the largest packet size for that is less
than 6KB. So change buf_len field to 8KB, which results in order 1
allocation if page size is 4KB. In this way, we can at least save some
memory, and as well as decrease the possibility of allocation failure
in those scenarios.
Tested-on: WCN6855 hw2.0 PCI WLAN.HSP.1.1-03125-QCAHSPSWPL_V1_V2_SILICONZ_LITE-3.6510.30
CVE-2024-35940:In the Linux kernel, the following vulnerability has been resolved:
pstore/zone: Add a null pointer check to the psz_kmsg_read
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
CVE-2024-35943:In the Linux kernel, the following vulnerability has been resolved:
pmdomain: ti: Add a null pointer check to the omap_prm_domain_init
devm_kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure. Ensure the allocation was successful
by checking the pointer validity.
CVE-2024-35997:In the Linux kernel, the following vulnerability has been resolved:
HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-up
The flag I2C_HID_READ_PENDING is used to serialize I2C operations.
However, this is not necessary, because I2C core already has its own
locking for that.
More importantly, this flag can cause a lock-up: if the flag is set in
i2c_hid_xfer() and an interrupt happens, the interrupt handler
(i2c_hid_irq) will check this flag and return immediately without doing
anything, then the interrupt handler will be invoked again in an
infinite loop.
Since interrupt handler is an RT task, it takes over the CPU and the
flag-clearing task never gets scheduled, thus we have a lock-up.
Delete this unnecessary flag.
CVE-2024-36006:In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix incorrect list API usage
Both the function that migrates all the chunks within a region and the
function that migrates all the entries within a chunk call
list_first_entry() on the respective lists without checking that the
lists are not empty. This is incorrect usage of the API, which leads to
the following warning [1].
Fix by returning if the lists are empty as there is nothing to migrate
in this case.
[1]
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;
Modules linked in:
CPU: 0 PID: 6437 Comm: kworker/0:37 Not tainted 6.9.0-rc3-custom-00883-g94a65f079ef6 #39
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:mlxsw_sp_acl_tcam_vchunk_migrate_all+0x1f1/0x2c0
[...]
Call Trace:
 &lt;TASK&gt;
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x6c/0x4a0
 process_one_work+0x151/0x370
 worker_thread+0x2cb/0x3e0
 kthread+0xd0/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
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.
CVE-2024-4853:Memory handling issue in editcap could cause denial of service via crafted capture file
CVE-2024-4855:Use after free issue in editcap could cause denial of service via crafted capture file</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.77.0.157.u121.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.77.0.157.u121.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.77.0.157.u121.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.77.0.157.u121.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.77.0.157.u121.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.77.0.157.u121.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.77.0.157.u121.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.77.0.157.u121.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.77.0.157.u121.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.77.0.157.u121.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.77.0.157.u121.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.77.0.157.u121.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.77.0.157.u121.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.77.0.157.u121.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.77.0.157.u121.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.77.0.157.u121.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.77.0.157.u121.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2201</id>
		<title>An update for libsndfile is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33065" id="CVE-2022-33065" title="CVE-2022-33065" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2202</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1916" id="CVE-2023-1916" title="CVE-2023-1916" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3164" id="CVE-2023-3164" title="CVE-2023-3164" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2203</id>
		<title>An update for libvirt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4418" id="CVE-2024-4418" title="CVE-2024-4418" type="cve"/>
		</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's stack frame was concurrently being &quot;freed&quot; when returning from virNetClientIOEventLoop(). The 'virtproxyd' 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2204</id>
		<title>An update for libxml2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34459" id="CVE-2024-34459" title="CVE-2024-34459" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2205</id>
		<title>An update for nautilus is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37290" id="CVE-2022-37290" title="CVE-2022-37290" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2206</id>
		<title>An update for python-PyMySQL is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36039" id="CVE-2024-36039" title="CVE-2024-36039" type="cve"/>
		</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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2207</id>
		<title>An update for python-gunicorn is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1135" id="CVE-2024-1135" title="CVE-2024-1135" type="cve"/>
		</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'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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2208</id>
		<title>An update for qt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45935" id="CVE-2023-45935" title="CVE-2023-45935" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2209</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27280" id="CVE-2024-27280" title="CVE-2024-27280" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27281" id="CVE-2024-27281" title="CVE-2024-27281" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2210</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-06-12"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4853" id="CVE-2024-4853" title="CVE-2024-4853" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4854" id="CVE-2024-4854" title="CVE-2024-4854" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4855" id="CVE-2024-4855" title="CVE-2024-4855" type="cve"/>
		</references>
		<description>CVE-2024-4853:Memory handling issue in editcap could cause denial of service via crafted capture file
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
CVE-2024-4855:Use after free issue in editcap could cause denial of service via crafted capture file</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2211</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-07-05"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6387" id="CVE-2024-6387" title="CVE-2024-6387" type="cve"/>
		</references>
		<description>CVE-2024-6387:A security regression (CVE-2006-5051) was discovered in OpenSSH'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2199" id="CVE-2024-2199" title="CVE-2024-2199" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3657" id="CVE-2024-3657" title="CVE-2024-3657" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2213</id>
		<title>An update for assimp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40724" id="CVE-2024-40724" title="CVE-2024-40724" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2214</id>
		<title>An update for bind is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1975" id="CVE-2024-1975" title="CVE-2024-1975" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4076" id="CVE-2024-4076" title="CVE-2024-4076" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1737" id="CVE-2024-1737" title="CVE-2024-1737" type="cve"/>
		</references>
		<description>CVE-2024-1975:If a server hosts a zone containing a &quot;KEY&quot; Resource Record, or a resolver DNSSEC-validates a &quot;KEY&quot; 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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2215</id>
		<title>An update for busybox is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42363" id="CVE-2023-42363" title="CVE-2023-42363" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2216</id>
		<title>An update for cockpit is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6126" id="CVE-2024-6126" title="CVE-2024-6126" type="cve"/>
		</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's user_readenv option, which leads to a denial of service (DoS) attack.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="cockpit" release="16.u4.fos23" version="178">
					<filename>cockpit-178-16.u4.fos23.aarch64.rpm</filename>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2217</id>
		<title>An update for cups is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35235" id="CVE-2024-35235" title="CVE-2024-35235" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2218</id>
		<title>An update for dnsjava is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25638" id="CVE-2024-25638" title="CVE-2024-25638" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2219</id>
		<title>An update for dnsmasq is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49441" id="CVE-2023-49441" title="CVE-2023-49441" type="cve"/>
		</references>
		<description>CVE-2023-49441:dnsmasq 2.9 is vulnerable to Integer Overflow via forward_query.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2220</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1298" id="CVE-2024-1298" title="CVE-2024-1298" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2221</id>
		<title>An update for emacs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39331" id="CVE-2024-39331" title="CVE-2024-39331" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2222</id>
		<title>An update for exiv2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39695" id="CVE-2024-39695" title="CVE-2024-39695" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2223</id>
		<title>An update for ffmpeg is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31578" id="CVE-2024-31578" title="CVE-2024-31578" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51794" id="CVE-2023-51794" title="CVE-2023-51794" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51798" id="CVE-2023-51798" title="CVE-2023-51798" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3341" id="CVE-2022-3341" title="CVE-2022-3341" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3109" id="CVE-2022-3109" title="CVE-2022-3109" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51793" id="CVE-2023-51793" title="CVE-2023-51793" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50010" id="CVE-2023-50010" title="CVE-2023-50010" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38171" id="CVE-2021-38171" title="CVE-2021-38171" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28429" id="CVE-2021-28429" title="CVE-2021-28429" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32230" id="CVE-2024-32230" title="CVE-2024-32230" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1475" id="CVE-2022-1475" title="CVE-2022-1475" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48434" id="CVE-2022-48434" title="CVE-2022-48434" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49528" id="CVE-2023-49528" title="CVE-2023-49528" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51791" id="CVE-2023-51791" title="CVE-2023-51791" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51797" id="CVE-2023-51797" title="CVE-2023-51797" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32229" id="CVE-2024-32229" title="CVE-2024-32229" type="cve"/>
		</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.
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.
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.
CVE-2022-3341:A null pointer dereference issue was discovered in 'FFmpeg' 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.
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.
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.
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.
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.
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.
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
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.
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).
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.
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.
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
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2224</id>
		<title>An update for freeradius is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3596" id="CVE-2024-3596" title="CVE-2024-3596" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2225</id>
		<title>An update for gdk-pixbuf2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48622" id="CVE-2022-48622" title="CVE-2022-48622" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2226</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29510" id="CVE-2024-29510" title="CVE-2024-29510" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33869" id="CVE-2024-33869" title="CVE-2024-33869" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33870" id="CVE-2024-33870" title="CVE-2024-33870" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29506" id="CVE-2024-29506" title="CVE-2024-29506" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29507" id="CVE-2024-29507" title="CVE-2024-29507" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29508" id="CVE-2024-29508" title="CVE-2024-29508" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29509" id="CVE-2024-29509" title="CVE-2024-29509" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29511" id="CVE-2024-29511" title="CVE-2024-29511" type="cve"/>
		</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.
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.
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.
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.
CVE-2024-29507:Artifex Ghostscript before 10.03.0 sometimes has a stack-based buffer overflow via the CIDFSubstPath and CIDFSubstFont parameters.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2227</id>
		<title>An update for glib2 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34397" id="CVE-2024-34397" title="CVE-2024-34397" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2228</id>
		<title>An update for golang is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24789" id="CVE-2024-24789" title="CVE-2024-24789" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24790" id="CVE-2024-24790" title="CVE-2024-24790" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45283" id="CVE-2023-45283" title="CVE-2023-45283" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-27664" id="CVE-2022-27664" title="CVE-2022-27664" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29804" id="CVE-2022-29804" title="CVE-2022-29804" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32189" id="CVE-2022-32189" title="CVE-2022-32189" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-30630" id="CVE-2022-30630" title="CVE-2022-30630" type="cve"/>
		</references>
		<description>CVE-2024-24789:The archive/zip package'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.
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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2229</id>
		<title>An update for grub2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46848" id="CVE-2021-46848" title="CVE-2021-46848" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2230</id>
		<title>An update for gtk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6655" id="CVE-2024-6655" title="CVE-2024-6655" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2231</id>
		<title>An update for gtk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6655" id="CVE-2024-6655" title="CVE-2024-6655" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2232</id>
		<title>An update for gtk3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6655" id="CVE-2024-6655" title="CVE-2024-6655" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2233</id>
		<title>An update for httpd is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38473" id="CVE-2024-38473" title="CVE-2024-38473" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38474" id="CVE-2024-38474" title="CVE-2024-38474" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38475" id="CVE-2024-38475" title="CVE-2024-38475" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38476" id="CVE-2024-38476" title="CVE-2024-38476" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38477" id="CVE-2024-38477" title="CVE-2024-38477" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39884" id="CVE-2024-39884" title="CVE-2024-39884" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39573" id="CVE-2024-39573" title="CVE-2024-39573" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38472" id="CVE-2024-38472" title="CVE-2024-38472" type="cve"/>
		</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.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
CVE-2024-38474:Substitution encoding issue in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows attacker to execute scripts in
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.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
Some RewriteRules that capture and substitute unsafely will now fail unless rewrite flag &quot;UnsafeAllow3F&quot; is specified.
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. 
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 &quot;UnsafePrefixStat&quot; can be used to opt back in once ensuring the substitution is appropriately constrained.
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.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
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.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
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.   &quot;AddType&quot; 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.
Users are recommended to upgrade to version 2.4.61, which fixes this issue.
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's to be handled by mod_proxy.
Users are recommended to upgrade to version 2.4.60, which fixes this issue.
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 
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 &quot;UNCList&quot; to allow access during request processing.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21085" id="CVE-2024-21085" title="CVE-2024-21085" type="cve"/>
		</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).
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).
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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21085" id="CVE-2024-21085" title="CVE-2024-21085" type="cve"/>
		</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).
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).
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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20932" id="CVE-2024-20932" title="CVE-2024-20932" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21012" id="CVE-2024-21012" title="CVE-2024-21012" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"/>
		</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).
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).
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).
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).
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2237</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26852" id="CVE-2024-26852" title="CVE-2024-26852" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52655" id="CVE-2023-52655" title="CVE-2023-52655" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35847" id="CVE-2024-35847" title="CVE-2024-35847" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35905" id="CVE-2024-35905" title="CVE-2024-35905" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35886" id="CVE-2024-35886" title="CVE-2024-35886" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35817" id="CVE-2024-35817" title="CVE-2024-35817" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35976" id="CVE-2024-35976" title="CVE-2024-35976" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52730" id="CVE-2023-52730" title="CVE-2023-52730" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52805" id="CVE-2023-52805" title="CVE-2023-52805" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52750" id="CVE-2023-52750" title="CVE-2023-52750" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52804" id="CVE-2023-52804" title="CVE-2023-52804" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52669" id="CVE-2023-52669" title="CVE-2023-52669" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35995" id="CVE-2024-35995" title="CVE-2024-35995" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35956" id="CVE-2024-35956" title="CVE-2024-35956" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52878" id="CVE-2023-52878" title="CVE-2023-52878" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52818" id="CVE-2023-52818" title="CVE-2023-52818" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52736" id="CVE-2023-52736" title="CVE-2023-52736" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35822" id="CVE-2024-35822" title="CVE-2024-35822" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47265" id="CVE-2021-47265" title="CVE-2021-47265" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52826" id="CVE-2023-52826" title="CVE-2023-52826" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52735" id="CVE-2023-52735" title="CVE-2023-52735" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52819" id="CVE-2023-52819" title="CVE-2023-52819" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52703" id="CVE-2023-52703" title="CVE-2023-52703" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52699" id="CVE-2023-52699" title="CVE-2023-52699" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52832" id="CVE-2023-52832" title="CVE-2023-52832" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52759" id="CVE-2023-52759" title="CVE-2023-52759" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52705" id="CVE-2023-52705" title="CVE-2023-52705" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52859" id="CVE-2023-52859" title="CVE-2023-52859" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27413" id="CVE-2024-27413" title="CVE-2024-27413" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52836" id="CVE-2023-52836" title="CVE-2023-52836" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47370" id="CVE-2021-47370" title="CVE-2021-47370" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35877" id="CVE-2024-35877" title="CVE-2024-35877" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52796" id="CVE-2023-52796" title="CVE-2023-52796" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52795" id="CVE-2023-52795" title="CVE-2023-52795" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36940" id="CVE-2024-36940" title="CVE-2024-36940" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47489" id="CVE-2021-47489" title="CVE-2021-47489" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35960" id="CVE-2024-35960" title="CVE-2024-35960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47427" id="CVE-2021-47427" title="CVE-2021-47427" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36924" id="CVE-2024-36924" title="CVE-2024-36924" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35939" id="CVE-2024-35939" title="CVE-2024-35939" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36000" id="CVE-2024-36000" title="CVE-2024-36000" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52670" id="CVE-2023-52670" title="CVE-2023-52670" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35823" id="CVE-2024-35823" title="CVE-2024-35823" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36015" id="CVE-2024-36015" title="CVE-2024-36015" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35958" id="CVE-2024-35958" title="CVE-2024-35958" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52789" id="CVE-2023-52789" title="CVE-2023-52789" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36898" id="CVE-2024-36898" title="CVE-2024-36898" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52808" id="CVE-2023-52808" title="CVE-2023-52808" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52774" id="CVE-2023-52774" title="CVE-2023-52774" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35950" id="CVE-2024-35950" title="CVE-2024-35950" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35989" id="CVE-2024-35989" title="CVE-2024-35989" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36906" id="CVE-2024-36906" title="CVE-2024-36906" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52799" id="CVE-2023-52799" title="CVE-2023-52799" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52746" id="CVE-2023-52746" title="CVE-2023-52746" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47558" id="CVE-2021-47558" title="CVE-2021-47558" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48689" id="CVE-2022-48689" title="CVE-2022-48689" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52752" id="CVE-2023-52752" title="CVE-2023-52752" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35895" id="CVE-2024-35895" title="CVE-2024-35895" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35896" id="CVE-2024-35896" title="CVE-2024-35896" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36964" id="CVE-2024-36964" title="CVE-2024-36964" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27399" id="CVE-2024-27399" title="CVE-2024-27399" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35855" id="CVE-2024-35855" title="CVE-2024-35855" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35888" id="CVE-2024-35888" title="CVE-2024-35888" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52677" id="CVE-2023-52677" title="CVE-2023-52677" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52800" id="CVE-2023-52800" title="CVE-2023-52800" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35790" id="CVE-2024-35790" title="CVE-2024-35790" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27402" id="CVE-2024-27402" title="CVE-2024-27402" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52798" id="CVE-2023-52798" title="CVE-2023-52798" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35854" id="CVE-2024-35854" title="CVE-2024-35854" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36021" id="CVE-2024-36021" title="CVE-2024-36021" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36900" id="CVE-2024-36900" title="CVE-2024-36900" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36017" id="CVE-2024-36017" title="CVE-2024-36017" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35853" id="CVE-2024-35853" title="CVE-2024-35853" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35910" id="CVE-2024-35910" title="CVE-2024-35910" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35937" id="CVE-2024-35937" title="CVE-2024-35937" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35925" id="CVE-2024-35925" title="CVE-2024-35925" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35821" id="CVE-2024-35821" title="CVE-2024-35821" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36029" id="CVE-2024-36029" title="CVE-2024-36029" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52739" id="CVE-2023-52739" title="CVE-2023-52739" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35887" id="CVE-2024-35887" title="CVE-2024-35887" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36904" id="CVE-2024-36904" title="CVE-2024-36904" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36889" id="CVE-2024-36889" title="CVE-2024-36889" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36957" id="CVE-2024-36957" title="CVE-2024-36957" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52756" id="CVE-2023-52756" title="CVE-2023-52756" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36886" id="CVE-2024-36886" title="CVE-2024-36886" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35870" id="CVE-2024-35870" title="CVE-2024-35870" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27393" id="CVE-2024-27393" title="CVE-2024-27393" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35967" id="CVE-2024-35967" title="CVE-2024-35967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52807" id="CVE-2023-52807" title="CVE-2023-52807" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35951" id="CVE-2024-35951" title="CVE-2024-35951" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36916" id="CVE-2024-36916" title="CVE-2024-36916" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52745" id="CVE-2023-52745" title="CVE-2023-52745" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36902" id="CVE-2024-36902" title="CVE-2024-36902" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35809" id="CVE-2024-35809" title="CVE-2024-35809" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52775" id="CVE-2023-52775" title="CVE-2023-52775" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36908" id="CVE-2024-36908" title="CVE-2024-36908" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36901" id="CVE-2024-36901" title="CVE-2024-36901" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36960" id="CVE-2024-36960" title="CVE-2024-36960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36929" id="CVE-2024-36929" title="CVE-2024-36929" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36952" id="CVE-2024-36952" title="CVE-2024-36952" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36933" id="CVE-2024-36933" title="CVE-2024-36933" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36883" id="CVE-2024-36883" title="CVE-2024-36883" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52680" id="CVE-2023-52680" title="CVE-2023-52680" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47247" id="CVE-2021-47247" title="CVE-2021-47247" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36899" id="CVE-2024-36899" title="CVE-2024-36899" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52672" id="CVE-2023-52672" title="CVE-2023-52672" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52732" id="CVE-2023-52732" title="CVE-2023-52732" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52882" id="CVE-2023-52882" title="CVE-2023-52882" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35924" id="CVE-2024-35924" title="CVE-2024-35924" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48652" id="CVE-2022-48652" title="CVE-2022-48652" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52693" id="CVE-2023-52693" title="CVE-2023-52693" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35915" id="CVE-2024-35915" title="CVE-2024-35915" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36949" id="CVE-2024-36949" title="CVE-2024-36949" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52708" id="CVE-2023-52708" title="CVE-2023-52708" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52762" id="CVE-2023-52762" title="CVE-2023-52762" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36905" id="CVE-2024-36905" title="CVE-2024-36905" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36928" id="CVE-2024-36928" title="CVE-2024-36928" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36919" id="CVE-2024-36919" title="CVE-2024-36919" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35830" id="CVE-2024-35830" title="CVE-2024-35830" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35828" id="CVE-2024-35828" title="CVE-2024-35828" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36016" id="CVE-2024-36016" title="CVE-2024-36016" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36938" id="CVE-2024-36938" title="CVE-2024-36938" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52747" id="CVE-2023-52747" title="CVE-2023-52747" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36914" id="CVE-2024-36914" title="CVE-2024-36914" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35796" id="CVE-2024-35796" title="CVE-2024-35796" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35966" id="CVE-2024-35966" title="CVE-2024-35966" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35932" id="CVE-2024-35932" title="CVE-2024-35932" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36953" id="CVE-2024-36953" title="CVE-2024-36953" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35965" id="CVE-2024-35965" title="CVE-2024-35965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36923" id="CVE-2024-36923" title="CVE-2024-36923" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26936" id="CVE-2024-26936" title="CVE-2024-26936" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39179" id="CVE-2023-39179" title="CVE-2023-39179" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26947" id="CVE-2024-26947" title="CVE-2024-26947" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52810" id="CVE-2023-52810" title="CVE-2023-52810" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52791" id="CVE-2023-52791" title="CVE-2023-52791" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26935" id="CVE-2024-26935" title="CVE-2024-26935" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35947" id="CVE-2024-35947" title="CVE-2024-35947" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36969" id="CVE-2024-36969" title="CVE-2024-36969" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38601" id="CVE-2024-38601" title="CVE-2024-38601" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38549" id="CVE-2024-38549" title="CVE-2024-38549" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35811" id="CVE-2024-35811" title="CVE-2024-35811" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36978" id="CVE-2024-36978" title="CVE-2024-36978" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38569" id="CVE-2024-38569" title="CVE-2024-38569" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38538" id="CVE-2024-38538" title="CVE-2024-38538" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38596" id="CVE-2024-38596" title="CVE-2024-38596" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36974" id="CVE-2024-36974" title="CVE-2024-36974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52696" id="CVE-2023-52696" title="CVE-2023-52696" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26661" id="CVE-2024-26661" title="CVE-2024-26661" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38634" id="CVE-2024-38634" title="CVE-2024-38634" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38605" id="CVE-2024-38605" title="CVE-2024-38605" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38545" id="CVE-2024-38545" title="CVE-2024-38545" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38633" id="CVE-2024-38633" title="CVE-2024-38633" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38632" id="CVE-2024-38632" title="CVE-2024-38632" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38591" id="CVE-2024-38591" title="CVE-2024-38591" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31076" id="CVE-2024-31076" title="CVE-2024-31076" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35955" id="CVE-2024-35955" title="CVE-2024-35955" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47381" id="CVE-2021-47381" title="CVE-2021-47381" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38555" id="CVE-2024-38555" title="CVE-2024-38555" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38577" id="CVE-2024-38577" title="CVE-2024-38577" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38599" id="CVE-2024-38599" title="CVE-2024-38599" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38564" id="CVE-2024-38564" title="CVE-2024-38564" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38630" id="CVE-2024-38630" title="CVE-2024-38630" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38624" id="CVE-2024-38624" title="CVE-2024-38624" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38589" id="CVE-2024-38589" title="CVE-2024-38589" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35969" id="CVE-2024-35969" title="CVE-2024-35969" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38544" id="CVE-2024-38544" title="CVE-2024-38544" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48772" id="CVE-2022-48772" title="CVE-2022-48772" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39276" id="CVE-2024-39276" title="CVE-2024-39276" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38625" id="CVE-2024-38625" title="CVE-2024-38625" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38552" id="CVE-2024-38552" title="CVE-2024-38552" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37354" id="CVE-2024-37354" title="CVE-2024-37354" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38541" id="CVE-2024-38541" title="CVE-2024-38541" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38661" id="CVE-2024-38661" title="CVE-2024-38661" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38597" id="CVE-2024-38597" title="CVE-2024-38597" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39292" id="CVE-2024-39292" title="CVE-2024-39292" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47618" id="CVE-2021-47618" title="CVE-2021-47618" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36014" id="CVE-2024-36014" title="CVE-2024-36014" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38590" id="CVE-2024-38590" title="CVE-2024-38590" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38620" id="CVE-2024-38620" title="CVE-2024-38620" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48761" id="CVE-2022-48761" title="CVE-2022-48761" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39461" id="CVE-2024-39461" title="CVE-2024-39461" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47441" id="CVE-2021-47441" title="CVE-2021-47441" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39462" id="CVE-2024-39462" title="CVE-2024-39462" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48720" id="CVE-2022-48720" title="CVE-2022-48720" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52884" id="CVE-2023-52884" title="CVE-2023-52884" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48748" id="CVE-2022-48748" title="CVE-2022-48748" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36481" id="CVE-2024-36481" title="CVE-2024-36481" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38384" id="CVE-2024-38384" title="CVE-2024-38384" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39470" id="CVE-2024-39470" title="CVE-2024-39470" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39465" id="CVE-2024-39465" title="CVE-2024-39465" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39466" id="CVE-2024-39466" title="CVE-2024-39466" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35785" id="CVE-2024-35785" title="CVE-2024-35785" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35949" id="CVE-2024-35949" title="CVE-2024-35949" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36931" id="CVE-2024-36931" title="CVE-2024-36931" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36937" id="CVE-2024-36937" title="CVE-2024-36937" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36028" id="CVE-2024-36028" title="CVE-2024-36028" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27405" id="CVE-2024-27405" title="CVE-2024-27405" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47568" id="CVE-2021-47568" title="CVE-2021-47568" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39492" id="CVE-2024-39492" title="CVE-2024-39492" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47598" id="CVE-2021-47598" title="CVE-2021-47598" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36965" id="CVE-2024-36965" title="CVE-2024-36965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47187" id="CVE-2021-47187" title="CVE-2021-47187" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52657" id="CVE-2023-52657" title="CVE-2023-52657" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35786" id="CVE-2024-35786" title="CVE-2024-35786" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27432" id="CVE-2024-27432" title="CVE-2024-27432" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52684" id="CVE-2023-52684" title="CVE-2023-52684" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35850" id="CVE-2024-35850" title="CVE-2024-35850" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52689" id="CVE-2023-52689" title="CVE-2023-52689" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52673" id="CVE-2023-52673" title="CVE-2023-52673" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52692" id="CVE-2023-52692" title="CVE-2023-52692" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47349" id="CVE-2021-47349" title="CVE-2021-47349" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47230" id="CVE-2021-47230" title="CVE-2021-47230" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35857" id="CVE-2024-35857" title="CVE-2024-35857" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47311" id="CVE-2021-47311" title="CVE-2021-47311" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47611" id="CVE-2021-47611" title="CVE-2021-47611" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47596" id="CVE-2021-47596" title="CVE-2021-47596" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47605" id="CVE-2021-47605" title="CVE-2021-47605" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48712" id="CVE-2022-48712" title="CVE-2022-48712" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48724" id="CVE-2022-48724" title="CVE-2022-48724" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48771" id="CVE-2022-48771" title="CVE-2022-48771" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48730" id="CVE-2022-48730" title="CVE-2022-48730" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48768" id="CVE-2022-48768" title="CVE-2022-48768" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38388" id="CVE-2024-38388" title="CVE-2024-38388" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48757" id="CVE-2022-48757" title="CVE-2022-48757" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47612" id="CVE-2021-47612" title="CVE-2021-47612" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38551" id="CVE-2024-38551" title="CVE-2024-38551" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38581" id="CVE-2024-38581" title="CVE-2024-38581" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38614" id="CVE-2024-38614" title="CVE-2024-38614" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39464" id="CVE-2024-39464" title="CVE-2024-39464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39463" id="CVE-2024-39463" title="CVE-2024-39463" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39479" id="CVE-2024-39479" title="CVE-2024-39479" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39478" id="CVE-2024-39478" title="CVE-2024-39478" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39502" id="CVE-2024-39502" title="CVE-2024-39502" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40997" id="CVE-2024-40997" title="CVE-2024-40997" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40964" id="CVE-2024-40964" title="CVE-2024-40964" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48732" id="CVE-2022-48732" title="CVE-2022-48732" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38628" id="CVE-2024-38628" title="CVE-2024-38628" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38572" id="CVE-2024-38572" title="CVE-2024-38572" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27416" id="CVE-2024-27416" title="CVE-2024-27416" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48822" id="CVE-2022-48822" title="CVE-2022-48822" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36935" id="CVE-2024-36935" title="CVE-2024-36935" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36955" id="CVE-2024-36955" title="CVE-2024-36955" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36956" id="CVE-2024-36956" title="CVE-2024-36956" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48807" id="CVE-2022-48807" title="CVE-2022-48807" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36973" id="CVE-2024-36973" title="CVE-2024-36973" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48837" id="CVE-2022-48837" title="CVE-2022-48837" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36951" id="CVE-2024-36951" title="CVE-2024-36951" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26978" id="CVE-2024-26978" title="CVE-2024-26978" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36967" id="CVE-2024-36967" title="CVE-2024-36967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36031" id="CVE-2024-36031" title="CVE-2024-36031" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36979" id="CVE-2024-36979" title="CVE-2024-36979" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36881" id="CVE-2024-36881" title="CVE-2024-36881" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34030" id="CVE-2024-34030" title="CVE-2024-34030" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38385" id="CVE-2024-38385" title="CVE-2024-38385" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39485" id="CVE-2024-39485" title="CVE-2024-39485" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40957" id="CVE-2024-40957" title="CVE-2024-40957" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40923" id="CVE-2024-40923" title="CVE-2024-40923" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40918" id="CVE-2024-40918" title="CVE-2024-40918" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40936" id="CVE-2024-40936" title="CVE-2024-40936" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40975" id="CVE-2024-40975" title="CVE-2024-40975" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40951" id="CVE-2024-40951" title="CVE-2024-40951" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40977" id="CVE-2024-40977" title="CVE-2024-40977" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48775" id="CVE-2022-48775" title="CVE-2022-48775" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48788" id="CVE-2022-48788" title="CVE-2022-48788" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48865" id="CVE-2022-48865" title="CVE-2022-48865" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48856" id="CVE-2022-48856" title="CVE-2022-48856" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48838" id="CVE-2022-48838" title="CVE-2022-48838" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38593" id="CVE-2024-38593" title="CVE-2024-38593" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36962" id="CVE-2024-36962" title="CVE-2024-36962" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38557" id="CVE-2024-38557" title="CVE-2024-38557" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38562" id="CVE-2024-38562" title="CVE-2024-38562" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38604" id="CVE-2024-38604" title="CVE-2024-38604" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38584" id="CVE-2024-38584" title="CVE-2024-38584" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38616" id="CVE-2024-38616" title="CVE-2024-38616" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47610" id="CVE-2021-47610" title="CVE-2021-47610" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52883" id="CVE-2023-52883" title="CVE-2023-52883" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38622" id="CVE-2024-38622" title="CVE-2024-38622" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38664" id="CVE-2024-38664" title="CVE-2024-38664" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39371" id="CVE-2024-39371" title="CVE-2024-39371" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39468" id="CVE-2024-39468" title="CVE-2024-39468" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47583" id="CVE-2021-47583" title="CVE-2021-47583" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48743" id="CVE-2022-48743" title="CVE-2022-48743" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35885" id="CVE-2024-35885" title="CVE-2024-35885" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35912" id="CVE-2024-35912" title="CVE-2024-35912" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35911" id="CVE-2024-35911" title="CVE-2024-35911" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35907" id="CVE-2024-35907" title="CVE-2024-35907" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35920" id="CVE-2024-35920" title="CVE-2024-35920" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35959" id="CVE-2024-35959" title="CVE-2024-35959" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35952" id="CVE-2024-35952" title="CVE-2024-35952" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47299" id="CVE-2021-47299" title="CVE-2021-47299" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47304" id="CVE-2021-47304" title="CVE-2021-47304" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47364" id="CVE-2021-47364" title="CVE-2021-47364" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47464" id="CVE-2021-47464" title="CVE-2021-47464" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47517" id="CVE-2021-47517" title="CVE-2021-47517" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47519" id="CVE-2021-47519" title="CVE-2021-47519" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47570" id="CVE-2021-47570" title="CVE-2021-47570" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47536" id="CVE-2021-47536" title="CVE-2021-47536" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36026" id="CVE-2024-36026" title="CVE-2024-36026" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36882" id="CVE-2024-36882" title="CVE-2024-36882" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36022" id="CVE-2024-36022" title="CVE-2024-36022" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36033" id="CVE-2024-36033" title="CVE-2024-36033" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36892" id="CVE-2024-36892" title="CVE-2024-36892" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36943" id="CVE-2024-36943" title="CVE-2024-36943" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36932" id="CVE-2024-36932" title="CVE-2024-36932" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4440" id="CVE-2021-4440" title="CVE-2021-4440" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24974" id="CVE-2024-24974" title="CVE-2024-24974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48738" id="CVE-2022-48738" title="CVE-2022-48738" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47351" id="CVE-2021-47351" title="CVE-2021-47351" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36030" id="CVE-2024-36030" title="CVE-2024-36030" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47430" id="CVE-2021-47430" title="CVE-2021-47430" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38610" id="CVE-2024-38610" title="CVE-2024-38610" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47296" id="CVE-2021-47296" title="CVE-2021-47296" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38580" id="CVE-2024-38580" title="CVE-2024-38580" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48760" id="CVE-2022-48760" title="CVE-2022-48760" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36965" id="CVE-2024-36965" title="CVE-2024-36965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38629" id="CVE-2024-38629" title="CVE-2024-38629" type="cve"/>
		</references>
		<description>CVE-2024-26852:In the Linux kernel, the following vulnerability has been resolved:
net/ipv6: avoid possible UAF in ip6_route_mpath_notify()
syzbot found another use-after-free in ip6_route_mpath_notify() [1]
Commit f7225172f25a (&quot;net/ipv6: prevent use after free in
ip6_route_mpath_notify&quot;) was not able to fix the root cause.
We need to defer the fib6_info_release() calls after
ip6_route_mpath_notify(), in the cleanup phase.
[1]
BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0
Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037
CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x1e7/0x2e0 lib/dump_stack.c:106
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0x167/0x540 mm/kasan/report.c:488
  kasan_report+0x142/0x180 mm/kasan/report.c:601
 rt6_fill_node+0x1460/0x1ac0
  inet6_rt_notify+0x13b/0x290 net/ipv6/route.c:6184
  ip6_route_mpath_notify net/ipv6/route.c:5198 [inline]
  ip6_route_multipath_add net/ipv6/route.c:5404 [inline]
  inet6_rtm_newroute+0x1d0f/0x2300 net/ipv6/route.c:5517
  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x221/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
  ___sys_sendmsg net/socket.c:2638 [inline]
  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
 do_syscall_64+0xf9/0x240
 entry_SYSCALL_64_after_hwframe+0x6f/0x77
RIP: 0033:0x7f73dd87dda9
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
RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9
RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005
RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000006e R14: 00007f73dd9ac050 R15: 00007ffdbdeb7858
 &lt;/TASK&gt;
Allocated by task 23037:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  poison_kmalloc_redzone mm/kasan/common.c:372 [inline]
  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:389
  kasan_kmalloc include/linux/kasan.h:211 [inline]
  __do_kmalloc_node mm/slub.c:3981 [inline]
  __kmalloc+0x22e/0x490 mm/slub.c:3994
  kmalloc include/linux/slab.h:594 [inline]
  kzalloc include/linux/slab.h:711 [inline]
  fib6_info_alloc+0x2e/0xf0 net/ipv6/ip6_fib.c:155
  ip6_route_info_create+0x445/0x12b0 net/ipv6/route.c:3758
  ip6_route_multipath_add net/ipv6/route.c:5298 [inline]
  inet6_rtm_newroute+0x744/0x2300 net/ipv6/route.c:5517
  rtnetlink_rcv_msg+0x885/0x1040 net/core/rtnetlink.c:6597
  netlink_rcv_skb+0x1e3/0x430 net/netlink/af_netlink.c:2543
  netlink_unicast_kernel net/netlink/af_netlink.c:1341 [inline]
  netlink_unicast+0x7ea/0x980 net/netlink/af_netlink.c:1367
  netlink_sendmsg+0xa3b/0xd70 net/netlink/af_netlink.c:1908
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x221/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2584
  ___sys_sendmsg net/socket.c:2638 [inline]
  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2667
 do_syscall_64+0xf9/0x240
 entry_SYSCALL_64_after_hwframe+0x6f/0x77
Freed by task 16:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  kasan_save_free_info+0x4e/0x60 mm/kasan/generic.c:640
  poison_slab_object+0xa6/0xe0 m
---truncated---
CVE-2023-52655:In the Linux kernel, the following vulnerability has been resolved:
usb: aqc111: check packet for fixup for true limit
If a device sends a packet that is inbetween 0
and sizeof(u64) the value passed to skb_trim()
as length will wrap around ending up as some very
large value.
The driver will then proceed to parse the header
located at that position, which will either oops or
process some random value.
The fix is to check against sizeof(u64) rather than
0, which the driver currently does. The issue exists
since the introduction of the driver.
CVE-2024-35847:In the Linux kernel, the following vulnerability has been resolved:
irqchip/gic-v3-its: Prevent double free on error
The error handling path in its_vpe_irq_domain_alloc() causes a double free
when its_vpe_init() fails after successfully allocating at least one
interrupt. This happens because its_vpe_irq_domain_free() frees the
interrupts along with the area bitmap and the vprop_page and
its_vpe_irq_domain_alloc() subsequently frees the area bitmap and the
vprop_page again.
Fix this by unconditionally invoking its_vpe_irq_domain_free() which
handles all cases correctly and by removing the bitmap/vprop_page freeing
from its_vpe_irq_domain_alloc().
[ tglx: Massaged change log ]
CVE-2024-35905:In the Linux kernel, the following vulnerability has been resolved:
bpf: Protect against int overflow for stack access size
This patch re-introduces protection against the size of access to stack
memory being negative; the access size can appear negative as a result
of overflowing its signed int representation. This should not actually
happen, as there are other protections along the way, but we should
protect against it anyway. One code path was missing such protections
(fixed in the previous patch in the series), causing out-of-bounds array
accesses in check_stack_range_initialized(). This patch causes the
verification of a program with such a non-sensical access size to fail.
This check used to exist in a more indirect way, but was inadvertendly
removed in a833a17aeac7.
CVE-2024-35886:In the Linux kernel, the following vulnerability has been resolved:
ipv6: Fix infinite recursion in fib6_dump_done().
syzkaller reported infinite recursive calls of fib6_dump_done() during
netlink socket destruction.  [1]
From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and then
the response was generated.  The following recvmmsg() resumed the dump
for IPv6, but the first call of inet6_dump_fib() failed at kzalloc() due
to the fault injection.  [0]
  12:01:34 executing program 3:
  r0 = socket$nl_route(0x10, 0x3, 0x0)
  sendmsg$nl_route(r0, ... snip ...)
  recvmmsg(r0, ... snip ...) (fail_nth: 8)
Here, fib6_dump_done() was set to nlk_sk(sk)-&gt;cb.done, and the next call
of inet6_dump_fib() set it to nlk_sk(sk)-&gt;cb.args[3].  syzkaller stopped
receiving the response halfway through, and finally netlink_sock_destruct()
called nlk_sk(sk)-&gt;cb.done().
fib6_dump_done() calls fib6_dump_end() and nlk_sk(sk)-&gt;cb.done() if it
is still not NULL.  fib6_dump_end() rewrites nlk_sk(sk)-&gt;cb.done() by
nlk_sk(sk)-&gt;cb.args[3], but it has the same function, not NULL, calling
itself recursively and hitting the stack guard page.
To avoid the issue, let's set the destructor after kzalloc().
[0]:
FAULT_INJECTION: forcing a failure.
name failslab, interval 1, probability 0, space 0, times 0
CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl (lib/dump_stack.c:117)
 should_fail_ex (lib/fault-inject.c:52 lib/fault-inject.c:153)
 should_failslab (mm/slub.c:3733)
 kmalloc_trace (mm/slub.c:3748 mm/slub.c:3827 mm/slub.c:3992)
 inet6_dump_fib (./include/linux/slab.h:628 ./include/linux/slab.h:749 net/ipv6/ip6_fib.c:662)
 rtnl_dump_all (net/core/rtnetlink.c:4029)
 netlink_dump (net/netlink/af_netlink.c:2269)
 netlink_recvmsg (net/netlink/af_netlink.c:1988)
 ____sys_recvmsg (net/socket.c:1046 net/socket.c:2801)
 ___sys_recvmsg (net/socket.c:2846)
 do_recvmmsg (net/socket.c:2943)
 __x64_sys_recvmmsg (net/socket.c:3041 net/socket.c:3034 net/socket.c:3034)
[1]:
BUG: TASK stack guard page was hit at 00000000f2fa9af1 (stack is 00000000b7912430..000000009a436beb)
stack guard page: 0000 [#1] PREEMPT SMP KASAN
CPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
Workqueue: events netlink_sock_destruct_work
RIP: 0010:fib6_dump_done (net/ipv6/ip6_fib.c:570)
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
RSP: 0018:ffffc9000d980000 EFLAGS: 00010293
RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3
RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358
RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000
R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68
FS:  0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
 &lt;#DF&gt;
 &lt;/#DF&gt;
 &lt;TASK&gt;
 fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
 fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
 ...
 fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
 fib6_dump_done (net/ipv6/ip6_fib.c:572 (discriminator 1))
 netlink_sock_destruct (net/netlink/af_netlink.c:401)
 __sk_destruct (net/core/sock.c:2177 (discriminator 2))
 sk_destruct (net/core/sock.c:2224)
 __sk_free (net/core/sock.c:2235)
 sk_free (net/core/sock.c:2246)
 process_one_work (kernel/workqueue.c:3259)
 worker_thread (kernel/workqueue.c:3329 kernel/workqueue.
---truncated---
CVE-2024-35817:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flag
Otherwise after the GTT bo is released, the GTT and gart space is freed
but amdgpu_ttm_backend_unbind will not clear the gart page table entry
and leave valid mapping entry pointing to the stale system page. Then
if GPU access the gart address mistakely, it will read undefined value
instead page fault, harder to debug and reproduce the real issue.
CVE-2024-35976:In the Linux kernel, the following vulnerability has been resolved:
xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RING
syzbot reported an illegal copy in xsk_setsockopt() [1]
Make sure to validate setsockopt() @optlen parameter.
[1]
 BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
 BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
 BUG: KASAN: slab-out-of-bounds in xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549
CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0x169/0x550 mm/kasan/report.c:488
  kasan_report+0x143/0x180 mm/kasan/report.c:601
  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
  copy_from_sockptr include/linux/sockptr.h:55 [inline]
  xsk_setsockopt+0x909/0xa40 net/xdp/xsk.c:1420
  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7fb40587de69
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
RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69
RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006
RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000
R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fb4059abf80 R15: 00007fff57ee4d08
 &lt;/TASK&gt;
Allocated by task 7549:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
  kasan_kmalloc include/linux/kasan.h:211 [inline]
  __do_kmalloc_node mm/slub.c:3966 [inline]
  __kmalloc+0x233/0x4a0 mm/slub.c:3979
  kmalloc include/linux/slab.h:632 [inline]
  __cgroup_bpf_run_filter_setsockopt+0xd2f/0x1040 kernel/bpf/cgroup.c:1869
  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
The buggy address belongs to the object at ffff888028c6cde0
 which belongs to the cache kmalloc-8 of size 8
The buggy address is located 1 bytes to the right of
 allocated 2-byte region [ffff888028c6cde0, ffff888028c6cde2)
The buggy address belongs to the physical page:
page:ffffea0000a31b00 refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff888028c6c9c0 pfn:0x28c6c
anon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)
page_type: 0xffffffff()
raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001
raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
page_owner tracks the page as allocated
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
  set_page_owner include/linux/page_owner.h:31 [inline]
  post_alloc_hook+0x1ea/0x210 mm/page_alloc.c:1533
  prep_new_page mm/page_alloc.c:
---truncated---
CVE-2023-52730:In the Linux kernel, the following vulnerability has been resolved:
mmc: sdio: fix possible resource leaks in some error paths
If sdio_add_func() or sdio_init_func() fails, sdio_remove_func() can
not release the resources, because the sdio function is not presented
in these two cases, it won't call of_node_put() or put_device().
To fix these leaks, make sdio_func_present() only control whether
device_del() needs to be called or not, then always call of_node_put()
and put_device().
In error case in sdio_init_func(), the reference of 'card-&gt;dev' is
not get, to avoid redundant put in sdio_free_func_cis(), move the
get_device() to sdio_alloc_func() and put_device() to sdio_release_func(),
it can keep the get/put function be balanced.
Without this patch, while doing fault inject test, it can get the
following leak reports, after this fix, the leak is gone.
unreferenced object 0xffff888112514000 (size 2048):
  comm &quot;kworker/3:2&quot;, pid 65, jiffies 4294741614 (age 124.774s)
  hex dump (first 32 bytes):
    00 e0 6f 12 81 88 ff ff 60 58 8d 06 81 88 ff ff  ..o.....`X......
    10 40 51 12 81 88 ff ff 10 40 51 12 81 88 ff ff  .@Q......@Q.....
  backtrace:
    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110
    [&lt;000000002f839ccb&gt;] mmc_alloc_card+0x38/0xb0 [mmc_core]
    [&lt;0000000004adcbf6&gt;] mmc_sdio_init_card+0xde/0x170 [mmc_core]
    [&lt;000000007538fea0&gt;] mmc_attach_sdio+0xcb/0x1b0 [mmc_core]
    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core]
unreferenced object 0xffff888112511000 (size 2048):
  comm &quot;kworker/3:2&quot;, pid 65, jiffies 4294741623 (age 124.766s)
  hex dump (first 32 bytes):
    00 40 51 12 81 88 ff ff e0 58 8d 06 81 88 ff ff  .@Q......X......
    10 10 51 12 81 88 ff ff 10 10 51 12 81 88 ff ff  ..Q.......Q.....
  backtrace:
    [&lt;000000009e5931da&gt;] kmalloc_trace+0x21/0x110
    [&lt;00000000fcbe706c&gt;] sdio_alloc_func+0x35/0x100 [mmc_core]
    [&lt;00000000c68f4b50&gt;] mmc_attach_sdio.cold.18+0xb1/0x395 [mmc_core]
    [&lt;00000000d4fdeba7&gt;] mmc_rescan+0x54a/0x640 [mmc_core]
CVE-2023-52805:In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in diAlloc
Currently there is not check against the agno of the iag while
allocating new inodes to avoid fragmentation problem. Added the check
which is required.
CVE-2023-52750:In the Linux kernel, the following vulnerability has been resolved:
arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newer
Prior to LLVM 15.0.0, LLVM's integrated assembler would incorrectly
byte-swap NOP when compiling for big-endian, and the resulting series of
bytes happened to match the encoding of FNMADD S21, S30, S0, S0.
This went unnoticed until commit:
  34f66c4c4d5518c1 (&quot;arm64: Use a positive cpucap for FP/SIMD&quot;)
Prior to that commit, the kernel would always enable the use of FPSIMD
early in boot when __cpu_setup() initialized CPACR_EL1, and so usage of
FNMADD within the kernel was not detected, but could result in the
corruption of user or kernel FPSIMD state.
After that commit, the instructions happen to trap during boot prior to
FPSIMD being detected and enabled, e.g.
| Unhandled 64-bit el1h sync exception on CPU0, ESR 0x000000001fe00000 -- ASIMD
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
| Hardware name: linux,dummy-virt (DT)
| pstate: 400000c9 (nZcv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
| pc : __pi_strcmp+0x1c/0x150
| lr : populate_properties+0xe4/0x254
| sp : ffffd014173d3ad0
| x29: ffffd014173d3af0 x28: fffffbfffddffcb8 x27: 0000000000000000
| x26: 0000000000000058 x25: fffffbfffddfe054 x24: 0000000000000008
| x23: fffffbfffddfe000 x22: fffffbfffddfe000 x21: fffffbfffddfe044
| x20: ffffd014173d3b70 x19: 0000000000000001 x18: 0000000000000005
| x17: 0000000000000010 x16: 0000000000000000 x15: 00000000413e7000
| x14: 0000000000000000 x13: 0000000000001bcc x12: 0000000000000000
| x11: 00000000d00dfeed x10: ffffd414193f2cd0 x9 : 0000000000000000
| x8 : 0101010101010101 x7 : ffffffffffffffc0 x6 : 0000000000000000
| x5 : 0000000000000000 x4 : 0101010101010101 x3 : 000000000000002a
| x2 : 0000000000000001 x1 : ffffd014171f2988 x0 : fffffbfffddffcb8
| Kernel panic - not syncing: Unhandled exception
| CPU: 0 PID: 0 Comm: swapper Not tainted 6.6.0-rc3-00013-g34f66c4c4d55 #1
| Hardware name: linux,dummy-virt (DT)
| Call trace:
|  dump_backtrace+0xec/0x108
|  show_stack+0x18/0x2c
|  dump_stack_lvl+0x50/0x68
|  dump_stack+0x18/0x24
|  panic+0x13c/0x340
|  el1t_64_irq_handler+0x0/0x1c
|  el1_abort+0x0/0x5c
|  el1h_64_sync+0x64/0x68
|  __pi_strcmp+0x1c/0x150
|  unflatten_dt_nodes+0x1e8/0x2d8
|  __unflatten_device_tree+0x5c/0x15c
|  unflatten_device_tree+0x38/0x50
|  setup_arch+0x164/0x1e0
|  start_kernel+0x64/0x38c
|  __primary_switched+0xbc/0xc4
Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which is
either GNU as or LLVM's IAS 15.0.0 and newer, which contains the linked
commit.
CVE-2023-52804:In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add validity check for db_maxag and db_agpref
Both db_maxag and db_agpref are used as the index of the
db_agfree array, but there is currently no validity check for
db_maxag and db_agpref, which can lead to errors.
The following is related bug reported by Syzbot:
UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:639:20
index 7936 is out of range for type 'atomic_t[128]'
Add checking that the values of db_maxag and db_agpref are valid
indexes for the db_agfree array.
CVE-2023-52669:In the Linux kernel, the following vulnerability has been resolved:
crypto: s390/aes - Fix buffer overread in CTR mode
When processing the last block, the s390 ctr code will always read
a whole block, even if there isn't a whole block of data left.  Fix
this by using the actual length left and copy it into a buffer first
for processing.
CVE-2024-35995:In the Linux kernel, the following vulnerability has been resolved:
ACPI: CPPC: Use access_width over bit_width for system memory accesses
To align with ACPI 6.3+, since bit_width can be any 8-bit value, it
cannot be depended on to be always on a clean 8b boundary. This was
uncovered on the Cobalt 100 platform.
SError Interrupt on CPU26, code 0xbe000011 -- SError
 CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted 5.15.2.1-13 #1
 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
 pstate: 62400009 (nZCv daif +PAN -UAO +TCO -DIT -SSBS BTYPE=--)
 pc : cppc_get_perf_caps+0xec/0x410
 lr : cppc_get_perf_caps+0xe8/0x410
 sp : ffff8000155ab730
 x29: ffff8000155ab730 x28: ffff0080139d0038 x27: ffff0080139d0078
 x26: 0000000000000000 x25: ffff0080139d0058 x24: 00000000ffffffff
 x23: ffff0080139d0298 x22: ffff0080139d0278 x21: 0000000000000000
 x20: ffff00802b251910 x19: ffff0080139d0000 x18: ffffffffffffffff
 x17: 0000000000000000 x16: ffffdc7e111bad04 x15: ffff00802b251008
 x14: ffffffffffffffff x13: ffff013f1fd63300 x12: 0000000000000006
 x11: ffffdc7e128f4420 x10: 0000000000000000 x9 : ffffdc7e111badec
 x8 : ffff00802b251980 x7 : 0000000000000000 x6 : ffff0080139d0028
 x5 : 0000000000000000 x4 : ffff0080139d0018 x3 : 00000000ffffffff
 x2 : 0000000000000008 x1 : ffff8000155ab7a0 x0 : 0000000000000000
 Kernel panic - not syncing: Asynchronous SError Interrupt
 CPU: 26 PID: 1510 Comm: systemd-udevd Not tainted
5.15.2.1-13 #1
 Hardware name: MICROSOFT CORPORATION, BIOS MICROSOFT CORPORATION
 Call trace:
  dump_backtrace+0x0/0x1e0
  show_stack+0x24/0x30
  dump_stack_lvl+0x8c/0xb8
  dump_stack+0x18/0x34
  panic+0x16c/0x384
  add_taint+0x0/0xc0
  arm64_serror_panic+0x7c/0x90
  arm64_is_fatal_ras_serror+0x34/0xa4
  do_serror+0x50/0x6c
  el1h_64_error_handler+0x40/0x74
  el1h_64_error+0x7c/0x80
  cppc_get_perf_caps+0xec/0x410
  cppc_cpufreq_cpu_init+0x74/0x400 [cppc_cpufreq]
  cpufreq_online+0x2dc/0xa30
  cpufreq_add_dev+0xc0/0xd4
  subsys_interface_register+0x134/0x14c
  cpufreq_register_driver+0x1b0/0x354
  cppc_cpufreq_init+0x1a8/0x1000 [cppc_cpufreq]
  do_one_initcall+0x50/0x250
  do_init_module+0x60/0x27c
  load_module+0x2300/0x2570
  __do_sys_finit_module+0xa8/0x114
  __arm64_sys_finit_module+0x2c/0x3c
  invoke_syscall+0x78/0x100
  el0_svc_common.constprop.0+0x180/0x1a0
  do_el0_svc+0x84/0xa0
  el0_svc+0x2c/0xc0
  el0t_64_sync_handler+0xa4/0x12c
  el0t_64_sync+0x1a4/0x1a8
Instead, use access_width to determine the size and use the offset and
width to shift and mask the bits to read/write out. Make sure to add a
check for system memory since pcc redefines the access_width to
subspace id.
If access_width is not set, then fall back to using bit_width.
[ rjw: Subject and changelog edits, comment adjustments ]
CVE-2024-35956:In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operations
Create subvolume, create snapshot and delete subvolume all use
btrfs_subvolume_reserve_metadata() to reserve metadata for the changes
done to the parent subvolume's fs tree, which cannot be mediated in the
normal way via start_transaction. When quota groups (squota or qgroups)
are enabled, this reserves qgroup metadata of type PREALLOC. Once the
operation is associated to a transaction, we convert PREALLOC to
PERTRANS, which gets cleared in bulk at the end of the transaction.
However, the error paths of these three operations were not implementing
this lifecycle correctly. They unconditionally converted the PREALLOC to
PERTRANS in a generic cleanup step regardless of errors or whether the
operation was fully associated to a transaction or not. This resulted in
error paths occasionally converting this rsv to PERTRANS without calling
record_root_in_trans successfully, which meant that unless that root got
recorded in the transaction by some other thread, the end of the
transaction would not free that root's PERTRANS, leaking it. Ultimately,
this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmount
for the leaked reservation.
The fix is to ensure that every qgroup PREALLOC reservation observes the
following properties:
1. any failure before record_root_in_trans is called successfully
   results in freeing the PREALLOC reservation.
2. after record_root_in_trans, we convert to PERTRANS, and now the
   transaction owns freeing the reservation.
This patch enforces those properties on the three operations. Without
it, generic/269 with squotas enabled at mkfs time would fail in ~5-10
runs on my system. With this patch, it ran successfully 1000 times in a
row.
CVE-2023-52878:In the Linux kernel, the following vulnerability has been resolved:
can: dev: can_put_echo_skb(): don't crash kernel if can_priv::echo_skb is accessed out of bounds
If the &quot;struct can_priv::echoo_skb&quot; is accessed out of bounds, this
would cause a kernel crash. Instead, issue a meaningful warning
message and return with an error.
CVE-2023-52818:In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7
For pptable structs that use flexible array sizes, use flexible arrays.
CVE-2023-52736:In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: Do not unset preset when cleaning up codec
Several functions that take part in codec's initialization and removal
are re-used by ASoC codec drivers implementations. Drivers mimic the
behavior of hda_codec_driver_probe/remove() found in
sound/pci/hda/hda_bind.c with their component-&gt;probe/remove() instead.
One of the reasons for that is the expectation of
snd_hda_codec_device_new() to receive a valid pointer to an instance of
struct snd_card. This expectation can be met only once sound card
components probing commences.
As ASoC sound card may be unbound without codec device being actually
removed from the system, unsetting -&gt;preset in
snd_hda_codec_cleanup_for_unbind() interferes with module unload -&gt; load
scenario causing null-ptr-deref. Preset is assigned only once, during
device/driver matching whereas ASoC codec driver's module reloading may
occur several times throughout the lifetime of an audio stack.
CVE-2024-35822:In the Linux kernel, the following vulnerability has been resolved:
usb: udc: remove warning when queue disabled ep
It is possible trigger below warning message from mass storage function,
WARNING: CPU: 6 PID: 3839 at drivers/usb/gadget/udc/core.c:294 usb_ep_queue+0x7c/0x104
pc : usb_ep_queue+0x7c/0x104
lr : fsg_main_thread+0x494/0x1b3c
Root cause is mass storage function try to queue request from main thread,
but other thread may already disable ep when function disable.
As there is no function failure in the driver, in order to avoid effort
to fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().
CVE-2021-47265:In the Linux kernel, the following vulnerability has been resolved:
RDMA: Verify port when creating flow rule
Validate port value provided by the user and with that remove no longer
needed validation by the driver.  The missing check in the mlx5_ib driver
could cause to the below oops.
Call trace:
  _create_flow_rule+0x2d4/0xf28 [mlx5_ib]
  mlx5_ib_create_flow+0x2d0/0x5b0 [mlx5_ib]
  ib_uverbs_ex_create_flow+0x4cc/0x624 [ib_uverbs]
  ib_uverbs_handler_UVERBS_METHOD_INVOKE_WRITE+0xd4/0x150 [ib_uverbs]
  ib_uverbs_cmd_verbs.isra.7+0xb28/0xc50 [ib_uverbs]
  ib_uverbs_ioctl+0x158/0x1d0 [ib_uverbs]
  do_vfs_ioctl+0xd0/0xaf0
  ksys_ioctl+0x84/0xb4
  __arm64_sys_ioctl+0x28/0xc4
  el0_svc_common.constprop.3+0xa4/0x254
  el0_svc_handler+0x84/0xa0
  el0_svc+0x10/0x26c
 Code: b9401260 f9615681 51000400 8b001c20 (f9403c1a)
CVE-2023-52826:In the Linux kernel, the following vulnerability has been resolved:
drm/panel/panel-tpo-tpg110: fix a possible null pointer dereference
In tpg110_get_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2023-52735:In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Don't let sock_map_{close,destroy,unhash} call itself
sock_map proto callbacks should never call themselves by design. Protect
against bugs like [1] and break out of the recursive loop to avoid a stack
overflow in favor of a resource leak.
[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/
CVE-2023-52819:In the Linux kernel, the following vulnerability has been resolved:
drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and Tonga
For pptable structs that use flexible array sizes, use flexible arrays.
CVE-2023-52703:In the Linux kernel, the following vulnerability has been resolved:
net/usb: kalmia: Don't pass act_len in usb_bulk_msg error path
syzbot reported that act_len in kalmia_send_init_packet() is
uninitialized when passing it to the first usb_bulk_msg error path. Jiri
Pirko noted that it's pointless to pass it in the error path, and that
the value that would be printed in the second error path would be the
value of act_len from the first call to usb_bulk_msg.[1]
With this in mind, let's just not pass act_len to the usb_bulk_msg error
paths.
1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/
CVE-2023-52699:In the Linux kernel, the following vulnerability has been resolved:
sysv: don't call sb_bread() with pointers_lock held
syzbot is reporting sleep in atomic context in SysV filesystem [1], for
sb_bread() is called with rw_spinlock held.
A &quot;write_lock(&amp;pointers_lock) =&gt; read_lock(&amp;pointers_lock) deadlock&quot; bug
and a &quot;sb_bread() with write_lock(&amp;pointers_lock)&quot; bug were introduced by
&quot;Replace BKL for chain locking with sysvfs-private rwlock&quot; in Linux 2.5.12.
Then, &quot;[PATCH] err1-40: sysvfs locking fix&quot; in Linux 2.6.8 fixed the
former bug by moving pointers_lock lock to the callers, but instead
introduced a &quot;sb_bread() with read_lock(&amp;pointers_lock)&quot; bug (which made
this problem easier to hit).
Al Viro suggested that why not to do like get_branch()/get_block()/
find_shared() in Minix filesystem does. And doing like that is almost a
revert of &quot;[PATCH] err1-40: sysvfs locking fix&quot; except that get_branch()
 from with find_shared() is called without write_lock(&amp;pointers_lock).
CVE-2023-52832:In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: don't return unset power in ieee80211_get_tx_power()
We can get a UBSAN warning if ieee80211_get_tx_power() returns the
INT_MIN value mac80211 internally uses for &quot;unset power level&quot;.
 UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5
 -2147483648 * 100 cannot be represented in type 'int'
 CPU: 0 PID: 20433 Comm: insmod Tainted: G        WC OE
 Call Trace:
  dump_stack+0x74/0x92
  ubsan_epilogue+0x9/0x50
  handle_overflow+0x8d/0xd0
  __ubsan_handle_mul_overflow+0xe/0x10
  nl80211_send_iface+0x688/0x6b0 [cfg80211]
  [...]
  cfg80211_register_wdev+0x78/0xb0 [cfg80211]
  cfg80211_netdev_notifier_call+0x200/0x620 [cfg80211]
  [...]
  ieee80211_if_add+0x60e/0x8f0 [mac80211]
  ieee80211_register_hw+0xda5/0x1170 [mac80211]
In this case, simply return an error instead, to indicate
that no data is available.
CVE-2023-52759:In the Linux kernel, the following vulnerability has been resolved:
gfs2: ignore negated quota changes
When lots of quota changes are made, there may be cases in which an
inode's quota information is increased and then decreased, such as when
blocks are added to a file, then deleted from it. If the timing is
right, function do_qc can add pending quota changes to a transaction,
then later, another call to do_qc can negate those changes, resulting
in a net gain of 0. The quota_change information is recorded in the qc
buffer (and qd element of the inode as well). The buffer is added to the
transaction by the first call to do_qc, but a subsequent call changes
the value from non-zero back to zero. At that point it's too late to
remove the buffer_head from the transaction. Later, when the quota sync
code is called, the zero-change qd element is discovered and flagged as
an assert warning. If the fs is mounted with errors=panic, the kernel
will panic.
This is usually seen when files are truncated and the quota changes are
negated by punch_hole/truncate which uses gfs2_quota_hold and
gfs2_quota_unhold rather than block allocations that use gfs2_quota_lock
and gfs2_quota_unlock which automatically do quota sync.
This patch solves the problem by adding a check to qd_check_sync such
that net-zero quota changes already added to the transaction are no
longer deemed necessary to be synced, and skipped.
In this case references are taken for the qd and the slot from do_qc
so those need to be put. The normal sequence of events for a normal
non-zero quota change is as follows:
gfs2_quota_change
   do_qc
      qd_hold
      slot_hold
Later, when the changes are to be synced:
gfs2_quota_sync
   qd_fish
      qd_check_sync
         gets qd ref via lockref_get_not_dead
   do_sync
      do_qc(QC_SYNC)
         qd_put
	    lockref_put_or_lock
   qd_unlock
      qd_put
         lockref_put_or_lock
In the net-zero change case, we add a check to qd_check_sync so it puts
the qd and slot references acquired in gfs2_quota_change and skip the
unneeded sync.
CVE-2023-52705:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix underflow in second superblock position calculations
Macro NILFS_SB2_OFFSET_BYTES, which computes the position of the second
superblock, underflows when the argument device size is less than 4096
bytes.  Therefore, when using this macro, it is necessary to check in
advance that the device size is not less than a lower limit, or at least
that underflow does not occur.
The current nilfs2 implementation lacks this check, causing out-of-bound
block access when mounting devices smaller than 4096 bytes:
 I/O error, dev loop0, sector 36028797018963960 op 0x0:(READ) flags 0x0
 phys_seg 1 prio class 2
 NILFS (loop0): unable to read secondary superblock (blocksize = 1024)
In addition, when trying to resize the filesystem to a size below 4096
bytes, this underflow occurs in nilfs_resize_fs(), passing a huge number
of segments to nilfs_sufile_resize(), corrupting parameters such as the
number of segments in superblocks.  This causes excessive loop iterations
in nilfs_sufile_resize() during a subsequent resize ioctl, causing
semaphore ns_segctor_sem to block for a long time and hang the writer
thread:
 INFO: task segctord:5067 blocked for more than 143 seconds.
      Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0
 &quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
 task:segctord        state:D stack:23456 pid:5067  ppid:2
 flags:0x00004000
 Call Trace:
  &lt;TASK&gt;
  context_switch kernel/sched/core.c:5293 [inline]
  __schedule+0x1409/0x43f0 kernel/sched/core.c:6606
  schedule+0xc3/0x190 kernel/sched/core.c:6682
  rwsem_down_write_slowpath+0xfcf/0x14a0 kernel/locking/rwsem.c:1190
  nilfs_transaction_lock+0x25c/0x4f0 fs/nilfs2/segment.c:357
  nilfs_segctor_thread_construct fs/nilfs2/segment.c:2486 [inline]
  nilfs_segctor_thread+0x52f/0x1140 fs/nilfs2/segment.c:2570
  kthread+0x270/0x300 kernel/kthread.c:376
  ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
  &lt;/TASK&gt;
 ...
 Call Trace:
  &lt;TASK&gt;
  folio_mark_accessed+0x51c/0xf00 mm/swap.c:515
  __nilfs_get_page_block fs/nilfs2/page.c:42 [inline]
  nilfs_grab_buffer+0x3d3/0x540 fs/nilfs2/page.c:61
  nilfs_mdt_submit_block+0xd7/0x8f0 fs/nilfs2/mdt.c:121
  nilfs_mdt_read_block+0xeb/0x430 fs/nilfs2/mdt.c:176
  nilfs_mdt_get_block+0x12d/0xbb0 fs/nilfs2/mdt.c:251
  nilfs_sufile_get_segment_usage_block fs/nilfs2/sufile.c:92 [inline]
  nilfs_sufile_truncate_range fs/nilfs2/sufile.c:679 [inline]
  nilfs_sufile_resize+0x7a3/0x12b0 fs/nilfs2/sufile.c:777
  nilfs_resize_fs+0x20c/0xed0 fs/nilfs2/super.c:422
  nilfs_ioctl_resize fs/nilfs2/ioctl.c:1033 [inline]
  nilfs_ioctl+0x137c/0x2440 fs/nilfs2/ioctl.c:1301
  ...
This fixes these issues by inserting appropriate minimum device size
checks or anti-underflow checks, depending on where the macro is used.
CVE-2023-52859:In the Linux kernel, the following vulnerability has been resolved:
perf: hisi: Fix use-after-free when register pmu fails
When we fail to register the uncore pmu, the pmu context may not been
allocated. The error handing will call cpuhp_state_remove_instance()
to call uncore pmu offline callback, which migrate the pmu context.
Since that's liable to lead to some kind of use-after-free.
Use cpuhp_state_remove_instance_nocalls() instead of
cpuhp_state_remove_instance() so that the notifiers don't execute after
the PMU device has been failed to register.
CVE-2024-27413:In the Linux kernel, the following vulnerability has been resolved:
efi/capsule-loader: fix incorrect allocation size
gcc-14 notices that the allocation with sizeof(void) on 32-bit architectures
is not enough for a 64-bit phys_addr_t:
drivers/firmware/efi/capsule-loader.c: In function 'efi_capsule_open':
drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size '4' for type 'phys_addr_t' {aka 'long long unsigned int'} with size '8' [-Werror=alloc-size]
  295 |         cap_info-&gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);
      |                        ^
Use the correct type instead here.
CVE-2023-52836:In the Linux kernel, the following vulnerability has been resolved:
locking/ww_mutex/test: Fix potential workqueue corruption
In some cases running with the test-ww_mutex code, I was seeing
odd behavior where sometimes it seemed flush_workqueue was
returning before all the work threads were finished.
Often this would cause strange crashes as the mutexes would be
freed while they were being used.
Looking at the code, there is a lifetime problem as the
controlling thread that spawns the work allocates the
&quot;struct stress&quot; structures that are passed to the workqueue
threads. Then when the workqueue threads are finished,
they free the stress struct that was passed to them.
Unfortunately the workqueue work_struct node is in the stress
struct. Which means the work_struct is freed before the work
thread returns and while flush_workqueue is waiting.
It seems like a better idea to have the controlling thread
both allocate and free the stress structures, so that we can
be sure we don't corrupt the workqueue by freeing the structure
prematurely.
So this patch reworks the test to do so, and with this change
I no longer see the early flush_workqueue returns.
CVE-2021-47370:In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure tx skbs always have the MPTCP ext
Due to signed/unsigned comparison, the expression:
	info-&gt;size_goal - skb-&gt;len &gt; 0
evaluates to true when the size goal is smaller than the
skb size. That results in lack of tx cache refill, so that
the skb allocated by the core TCP code lacks the required
MPTCP skb extensions.
Due to the above, syzbot is able to trigger the following WARN_ON():
WARNING: CPU: 1 PID: 810 at net/mptcp/protocol.c:1366 mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
Modules linked in:
CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366
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
RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216
RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000
RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003
RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280
R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0
FS:  00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 __mptcp_push_pending+0x1fb/0x6b0 net/mptcp/protocol.c:1547
 mptcp_release_cb+0xfe/0x210 net/mptcp/protocol.c:3003
 release_sock+0xb4/0x1b0 net/core/sock.c:3206
 sk_stream_wait_memory+0x604/0xed0 net/core/stream.c:145
 mptcp_sendmsg+0xc39/0x1bc0 net/mptcp/protocol.c:1749
 inet6_sendmsg+0x99/0xe0 net/ipv6/af_inet6.c:643
 sock_sendmsg_nosec net/socket.c:704 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:724
 sock_write_iter+0x2a0/0x3e0 net/socket.c:1057
 call_write_iter include/linux/fs.h:2163 [inline]
 new_sync_write+0x40b/0x640 fs/read_write.c:507
 vfs_write+0x7cf/0xae0 fs/read_write.c:594
 ksys_write+0x1ee/0x250 fs/read_write.c:647
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x4665f9
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
RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9
RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003
RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038
R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000
Fix the issue rewriting the relevant expression to avoid
sign-related problems - note: size_goal is always &gt;= 0.
Additionally, ensure that the skb in the tx cache always carries
the relevant extension.
CVE-2024-35877:In the Linux kernel, the following vulnerability has been resolved:
x86/mm/pat: fix VM_PAT handling in COW mappings
PAT handling won't do the right thing in COW mappings: the first PTE (or,
in fact, all PTEs) can be replaced during write faults to point at anon
folios.  Reliably recovering the correct PFN and cachemode using
follow_phys() from PTEs will not work in COW mappings.
Using follow_phys(), we might just get the address+protection of the anon
folio (which is very wrong), or fail on swap/nonswap entries, failing
follow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() and
track_pfn_copy(), not properly calling free_pfn_range().
In free_pfn_range(), we either wouldn't call memtype_free() or would call
it with the wrong range, possibly leaking memory.
To fix that, let's update follow_phys() to refuse returning anon folios,
and fallback to using the stored PFN inside vma-&gt;vm_pgoff for COW mappings
if we run into that.
We will now properly handle untrack_pfn() with COW mappings, where we
don't need the cachemode.  We'll have to fail fork()-&gt;track_pfn_copy() if
the first page was replaced by an anon folio, though: we'd have to store
the cachemode in the VMA to make this work, likely growing the VMA size.
For now, lets keep it simple and let track_pfn_copy() just fail in that
case: it would have failed in the past with swap/nonswap entries already,
and it would have done the wrong thing with anon folios.
Simple reproducer to trigger the WARN_ON_ONCE() in untrack_pfn():
&lt;--- C reproducer ---&gt;
 #include &lt;stdio.h&gt;
 #include &lt;sys/mman.h&gt;
 #include &lt;unistd.h&gt;
 #include &lt;liburing.h&gt;
 int main(void)
 {
         struct io_uring_params p = {};
         int ring_fd;
         size_t size;
         char *map;
         ring_fd = io_uring_setup(1, &amp;p);
         if (ring_fd &lt; 0) {
                 perror(&quot;io_uring_setup&quot;);
                 return 1;
         }
         size = p.sq_off.array + p.sq_entries * sizeof(unsigned);
         /* Map the submission queue ring MAP_PRIVATE */
         map = mmap(0, size, PROT_READ | PROT_WRITE, MAP_PRIVATE,
                    ring_fd, IORING_OFF_SQ_RING);
         if (map == MAP_FAILED) {
                 perror(&quot;mmap&quot;);
                 return 1;
         }
         /* We have at least one page. Let's COW it. */
         *map = 0;
         pause();
         return 0;
 }
&lt;--- C reproducer ---&gt;
On a system with 16 GiB RAM and swap configured:
 # ./iouring &amp;
 # memhog 16G
 # killall iouring
[  301.552930] ------------[ cut here ]------------
[  301.553285] WARNING: CPU: 7 PID: 1402 at arch/x86/mm/pat/memtype.c:1060 untrack_pfn+0xf4/0x100
[  301.553989] Modules linked in: binfmt_misc nft_fib_inet nft_fib_ipv4 nft_fib_ipv6 nft_fib nft_reject_g
[  301.558232] CPU: 7 PID: 1402 Comm: iouring Not tainted 6.7.5-100.fc38.x86_64 #1
[  301.558772] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebu4
[  301.559569] RIP: 0010:untrack_pfn+0xf4/0x100
[  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
[  301.561189] RSP: 0018:ffffba2c0377fab8 EFLAGS: 00010282
[  301.561590] RAX: 00000000ffffffea RBX: ffff9208c8ce9cc0 RCX: 000000010455e047
[  301.562105] RDX: 07fffffff0eb1e0a RSI: 0000000000000000 RDI: ffff9208c391d200
[  301.562628] RBP: 0000000000000000 R08: ffffba2c0377fab8 R09: 0000000000000000
[  301.563145] R10: ffff9208d2292d50 R11: 0000000000000002 R12: 00007fea890e0000
[  301.563669] R13: 0000000000000000 R14: ffffba2c0377fc08 R15: 0000000000000000
[  301.564186] FS:  0000000000000000(0000) GS:ffff920c2fbc0000(0000) knlGS:0000000000000000
[  301.564773] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  301.565197] CR2: 00007fea88ee8a20 CR3: 00000001033a8000 CR4: 0000000000750ef0
[  301.565725] PKRU: 55555554
[  301.565944] Call Trace:
[  301.566148]  &lt;TASK&gt;
[  301.566325]  ? untrack_pfn+0xf4/0x100
[  301.566618]  ? __warn+0x81/0x130
[  301.566876]  ? untrack_pfn+0xf4/0x100
[  3
---truncated---
CVE-2023-52796:In the Linux kernel, the following vulnerability has been resolved:
ipvlan: add ipvlan_route_v6_outbound() helper
Inspired by syzbot reports using a stack of multiple ipvlan devices.
Reduce stack size needed in ipvlan_process_v6_outbound() by moving
the flowi6 struct used for the route lookup in an non inlined
helper. ipvlan_route_v6_outbound() needs 120 bytes on the stack,
immediately reclaimed.
Also make sure ipvlan_process_v4_outbound() is not inlined.
We might also have to lower MAX_NEST_DEV, because only syzbot uses
setups with more than four stacked devices.
BUG: TASK stack guard page was hit at ffffc9000e803ff8 (stack is ffffc9000e804000..ffffc9000e808000)
stack guard page: 0000 [#1] SMP KASAN
CPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023
RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188
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
RSP: 0018:ffffc9000e804000 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2
RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568
RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080c
R13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000
FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
&lt;#DF&gt;
&lt;/#DF&gt;
&lt;TASK&gt;
[&lt;ffffffff81f281d1&gt;] __kasan_check_read+0x11/0x20 mm/kasan/shadow.c:31
[&lt;ffffffff817e5bf2&gt;] instrument_atomic_read include/linux/instrumented.h:72 [inline]
[&lt;ffffffff817e5bf2&gt;] _test_bit include/asm-generic/bitops/instrumented-non-atomic.h:141 [inline]
[&lt;ffffffff817e5bf2&gt;] cpumask_test_cpu include/linux/cpumask.h:506 [inline]
[&lt;ffffffff817e5bf2&gt;] cpu_online include/linux/cpumask.h:1092 [inline]
[&lt;ffffffff817e5bf2&gt;] trace_lock_acquire include/trace/events/lock.h:24 [inline]
[&lt;ffffffff817e5bf2&gt;] lock_acquire+0xe2/0x590 kernel/locking/lockdep.c:5632
[&lt;ffffffff8563221e&gt;] rcu_lock_acquire+0x2e/0x40 include/linux/rcupdate.h:306
[&lt;ffffffff8561464d&gt;] rcu_read_lock include/linux/rcupdate.h:747 [inline]
[&lt;ffffffff8561464d&gt;] ip6_pol_route+0x15d/0x1440 net/ipv6/route.c:2221
[&lt;ffffffff85618120&gt;] ip6_pol_route_output+0x50/0x80 net/ipv6/route.c:2606
[&lt;ffffffff856f65b5&gt;] pol_lookup_func include/net/ip6_fib.h:584 [inline]
[&lt;ffffffff856f65b5&gt;] fib6_rule_lookup+0x265/0x620 net/ipv6/fib6_rules.c:116
[&lt;ffffffff85618009&gt;] ip6_route_output_flags_noref+0x2d9/0x3a0 net/ipv6/route.c:2638
[&lt;ffffffff8561821a&gt;] ip6_route_output_flags+0xca/0x340 net/ipv6/route.c:2651
[&lt;ffffffff838bd5a3&gt;] ip6_route_output include/net/ip6_route.h:100 [inline]
[&lt;ffffffff838bd5a3&gt;] ipvlan_process_v6_outbound drivers/net/ipvlan/ipvlan_core.c:473 [inline]
[&lt;ffffffff838bd5a3&gt;] ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:529 [inline]
[&lt;ffffffff838bd5a3&gt;] ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
[&lt;ffffffff838bd5a3&gt;] ipvlan_queue_xmit+0xc33/0x1be0 drivers/net/ipvlan/ipvlan_core.c:677
[&lt;ffffffff838c2909&gt;] ipvlan_start_xmit+0x49/0x100 drivers/net/ipvlan/ipvlan_main.c:229
[&lt;ffffffff84d03900&gt;] netdev_start_xmit include/linux/netdevice.h:4966 [inline]
[&lt;ffffffff84d03900&gt;] xmit_one net/core/dev.c:3644 [inline]
[&lt;ffffffff84d03900&gt;] dev_hard_start_xmit+0x320/0x980 net/core/dev.c:3660
[&lt;ffffffff84d080e2&gt;] __dev_queue_xmit+0x16b2/0x3370 net/core/dev.c:4324
[&lt;ffffffff855ce4cd&gt;] dev_queue_xmit include/linux/netdevice.h:3067 [inline]
[&lt;ffffffff855ce4cd&gt;] neigh_hh_output include/net/neighbour.h:529 [inline]
[&lt;f
---truncated---
CVE-2023-52795:In the Linux kernel, the following vulnerability has been resolved:
vhost-vdpa: fix use after free in vhost_vdpa_probe()
The put_device() calls vhost_vdpa_release_dev() which calls
ida_simple_remove() and frees &quot;v&quot;.  So this call to
ida_simple_remove() is a use after free and a double free.
CVE-2024-36940:In the Linux kernel, the following vulnerability has been resolved:
pinctrl: core: delete incorrect free in pinctrl_enable()
The &quot;pctldev&quot; struct is allocated in devm_pinctrl_register_and_init().
It's a devm_ managed pointer that is freed by devm_pinctrl_dev_release(),
so freeing it in pinctrl_enable() will lead to a double free.
The devm_pinctrl_dev_release() function frees the pindescs and destroys
the mutex as well.
CVE-2021-47489:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix even more out of bound writes from debugfs
CVE-2021-42327 was fixed by:
commit f23750b5b3d98653b31d4469592935ef6364ad67
Author: Thelford Williams &lt;tdwilliamsiv@gmail.com&gt;
Date:   Wed Oct 13 16:04:13 2021 -0400
    drm/amdgpu: fix out of bounds write
but amdgpu_dm_debugfs.c contains more of the same issue so fix the
remaining ones.
v2:
	* Add missing fix in dp_max_bpc_write (Harry Wentland)
CVE-2024-35960:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Properly link new fs rules into the tree
Previously, add_rule_fg would only add newly created rules from the
handle into the tree when they had a refcount of 1. On the other hand,
create_flow_handle tries hard to find and reference already existing
identical rules instead of creating new ones.
These two behaviors can result in a situation where create_flow_handle
1) creates a new rule and references it, then
2) in a subsequent step during the same handle creation references it
   again,
resulting in a rule with a refcount of 2 that is not linked into the
tree, will have a NULL parent and root and will result in a crash when
the flow group is deleted because del_sw_hw_rule, invoked on rule
deletion, assumes node-&gt;parent is != NULL.
This happened in the wild, due to another bug related to incorrect
handling of duplicate pkt_reformat ids, which lead to the code in
create_flow_handle incorrectly referencing a just-added rule in the same
flow handle, resulting in the problem described above. Full details are
at [1].
This patch changes add_rule_fg to add new rules without parents into
the tree, properly initializing them and avoiding the crash. This makes
it more consistent with how rules are added to an FTE in
create_flow_handle.
CVE-2021-47427:In the Linux kernel, the following vulnerability has been resolved:
scsi: iscsi: Fix iscsi_task use after free
Commit d39df158518c (&quot;scsi: iscsi: Have abort handler get ref to conn&quot;)
added iscsi_get_conn()/iscsi_put_conn() calls during abort handling but
then also changed the handling of the case where we detect an already
completed task where we now end up doing a goto to the common put/cleanup
code. This results in a iscsi_task use after free, because the common
cleanup code will do a put on the iscsi_task.
This reverts the goto and moves the iscsi_get_conn() to after we've checked
if the iscsi_task is valid.
CVE-2024-36924:In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Release hbalock before calling lpfc_worker_wake_up()
lpfc_worker_wake_up() calls the lpfc_work_done() routine, which takes the
hbalock.  Thus, lpfc_worker_wake_up() should not be called while holding the
hbalock to avoid potential deadlock.
CVE-2024-35939:In the Linux kernel, the following vulnerability has been resolved:
dma-direct: Leak pages on dma_set_decrypted() failure
On TDX it is possible for the untrusted host to cause
set_memory_encrypted() or set_memory_decrypted() to fail such that an
error is returned and the resulting memory is shared. Callers need to
take care to handle these errors to avoid returning decrypted (shared)
memory to the page allocator, which could lead to functional or security
issues.
DMA could free decrypted/shared pages if dma_set_decrypted() fails. This
should be a rare case. Just leak the pages in this case instead of
freeing them.
CVE-2024-36000:In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix missing hugetlb_lock for resv uncharge
There is a recent report on UFFDIO_COPY over hugetlb:
https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/
350:	lockdep_assert_held(&amp;hugetlb_lock);
Should be an issue in hugetlb but triggered in an userfault context, where
it goes into the unlikely path where two threads modifying the resv map
together.  Mike has a fix in that path for resv uncharge but it looks like
the locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()
will update the cgroup pointer, so it requires to be called with the lock
held.
CVE-2023-52670:In the Linux kernel, the following vulnerability has been resolved:
rpmsg: virtio: Free driver_override when rpmsg_remove()
Free driver_override when rpmsg_remove(), otherwise
the following memory leak will occur:
unreferenced object 0xffff0000d55d7080 (size 128):
  comm &quot;kworker/u8:2&quot;, pid 56, jiffies 4294893188 (age 214.272s)
  hex dump (first 32 bytes):
    72 70 6d 73 67 5f 6e 73 00 00 00 00 00 00 00 00  rpmsg_ns........
    00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
  backtrace:
    [&lt;000000009c94c9c1&gt;] __kmem_cache_alloc_node+0x1f8/0x320
    [&lt;000000002300d89b&gt;] __kmalloc_node_track_caller+0x44/0x70
    [&lt;00000000228a60c3&gt;] kstrndup+0x4c/0x90
    [&lt;0000000077158695&gt;] driver_set_override+0xd0/0x164
    [&lt;000000003e9c4ea5&gt;] rpmsg_register_device_override+0x98/0x170
    [&lt;000000001c0c89a8&gt;] rpmsg_ns_register_device+0x24/0x30
    [&lt;000000008bbf8fa2&gt;] rpmsg_probe+0x2e0/0x3ec
    [&lt;00000000e65a68df&gt;] virtio_dev_probe+0x1c0/0x280
    [&lt;00000000443331cc&gt;] really_probe+0xbc/0x2dc
    [&lt;00000000391064b1&gt;] __driver_probe_device+0x78/0xe0
    [&lt;00000000a41c9a5b&gt;] driver_probe_device+0xd8/0x160
    [&lt;000000009c3bd5df&gt;] __device_attach_driver+0xb8/0x140
    [&lt;0000000043cd7614&gt;] bus_for_each_drv+0x7c/0xd4
    [&lt;000000003b929a36&gt;] __device_attach+0x9c/0x19c
    [&lt;00000000a94e0ba8&gt;] device_initial_probe+0x14/0x20
    [&lt;000000003c999637&gt;] bus_probe_device+0xa0/0xac
CVE-2024-35823:In the Linux kernel, the following vulnerability has been resolved:
vt: fix unicode buffer corruption when deleting characters
This is the same issue that was fixed for the VGA text buffer in commit
39cdb68c64d8 (&quot;vt: fix memory overlapping when deleting chars in the
buffer&quot;). The cure is also the same i.e. replace memcpy() with memmove()
due to the overlaping buffers.
CVE-2024-36015:In the Linux kernel, the following vulnerability has been resolved:
ppdev: Add an error check in register_device
In register_device, the return value of ida_simple_get is unchecked,
in witch ida_simple_get will use an invalid index value.
To address this issue, index should be checked after ida_simple_get. When
the index value is abnormal, a warning message should be printed, the port
should be dropped, and the value should be recorded.
CVE-2024-35958:In the Linux kernel, the following vulnerability has been resolved:
net: ena: Fix incorrect descriptor free behavior
ENA has two types of TX queues:
- queues which only process TX packets arriving from the network stack
- queues which only process TX packets forwarded to it by XDP_REDIRECT
  or XDP_TX instructions
The ena_free_tx_bufs() cycles through all descriptors in a TX queue
and unmaps + frees every descriptor that hasn't been acknowledged yet
by the device (uncompleted TX transactions).
The function assumes that the processed TX queue is necessarily from
the first category listed above and ends up using napi_consume_skb()
for descriptors belonging to an XDP specific queue.
This patch solves a bug in which, in case of a VF reset, the
descriptors aren't freed correctly, leading to crashes.
CVE-2023-52789:In the Linux kernel, the following vulnerability has been resolved:
tty: vcc: Add check for kstrdup() in vcc_probe()
Add check for the return value of kstrdup() and return the error, if it
fails in order to avoid NULL pointer dereference.
CVE-2024-36898:In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: fix uninitialised kfifo
If a line is requested with debounce, and that results in debouncing
in software, and the line is subsequently reconfigured to enable edge
detection then the allocation of the kfifo to contain edge events is
overlooked.  This results in events being written to and read from an
uninitialised kfifo.  Read events are returned to userspace.
Initialise the kfifo in the case where the software debounce is
already active.
CVE-2023-52808:In the Linux kernel, the following vulnerability has been resolved:
scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfs
If init debugfs failed during device registration due to memory allocation
failure, debugfs_remove_recursive() is called, after which debugfs_dir is
not set to NULL. debugfs_remove_recursive() will be called again during
device removal. As a result, illegal pointer is accessed.
[ 1665.467244] hisi_sas_v3_hw 0000:b4:02.0: failed to init debugfs!
...
[ 1669.836708] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000a0
[ 1669.872669] pc : down_write+0x24/0x70
[ 1669.876315] lr : down_write+0x1c/0x70
[ 1669.879961] sp : ffff000036f53a30
[ 1669.883260] x29: ffff000036f53a30 x28: ffffa027c31549f8
[ 1669.888547] x27: ffffa027c3140000 x26: 0000000000000000
[ 1669.893834] x25: ffffa027bf37c270 x24: ffffa027bf37c270
[ 1669.899122] x23: ffff0000095406b8 x22: ffff0000095406a8
[ 1669.904408] x21: 0000000000000000 x20: ffffa027bf37c310
[ 1669.909695] x19: 00000000000000a0 x18: ffff8027dcd86f10
[ 1669.914982] x17: 0000000000000000 x16: 0000000000000000
[ 1669.920268] x15: 0000000000000000 x14: ffffa0274014f870
[ 1669.925555] x13: 0000000000000040 x12: 0000000000000228
[ 1669.930842] x11: 0000000000000020 x10: 0000000000000bb0
[ 1669.936129] x9 : ffff000036f537f0 x8 : ffff80273088ca10
[ 1669.941416] x7 : 000000000000001d x6 : 00000000ffffffff
[ 1669.946702] x5 : ffff000008a36310 x4 : ffff80273088be00
[ 1669.951989] x3 : ffff000009513e90 x2 : 0000000000000000
[ 1669.957276] x1 : 00000000000000a0 x0 : ffffffff00000001
[ 1669.962563] Call trace:
[ 1669.965000]  down_write+0x24/0x70
[ 1669.968301]  debugfs_remove_recursive+0x5c/0x1b0
[ 1669.972905]  hisi_sas_debugfs_exit+0x24/0x30 [hisi_sas_main]
[ 1669.978541]  hisi_sas_v3_remove+0x130/0x150 [hisi_sas_v3_hw]
[ 1669.984175]  pci_device_remove+0x48/0xd8
[ 1669.988082]  device_release_driver_internal+0x1b4/0x250
[ 1669.993282]  device_release_driver+0x28/0x38
[ 1669.997534]  pci_stop_bus_device+0x84/0xb8
[ 1670.001611]  pci_stop_and_remove_bus_device_locked+0x24/0x40
[ 1670.007244]  remove_store+0xfc/0x140
[ 1670.010802]  dev_attr_store+0x44/0x60
[ 1670.014448]  sysfs_kf_write+0x58/0x80
[ 1670.018095]  kernfs_fop_write+0xe8/0x1f0
[ 1670.022000]  __vfs_write+0x60/0x190
[ 1670.025472]  vfs_write+0xac/0x1c0
[ 1670.028771]  ksys_write+0x6c/0xd8
[ 1670.032071]  __arm64_sys_write+0x24/0x30
[ 1670.035977]  el0_svc_common+0x78/0x130
[ 1670.039710]  el0_svc_handler+0x38/0x78
[ 1670.043442]  el0_svc+0x8/0xc
To fix this, set debugfs_dir to NULL after debugfs_remove_recursive().
CVE-2023-52774:In the Linux kernel, the following vulnerability has been resolved:
s390/dasd: protect device queue against concurrent access
In dasd_profile_start() the amount of requests on the device queue are
counted. The access to the device queue is unprotected against
concurrent access. With a lot of parallel I/O, especially with alias
devices enabled, the device queue can change while dasd_profile_start()
is accessing the queue. In the worst case this leads to a kernel panic
due to incorrect pointer accesses.
Fix this by taking the device lock before accessing the queue and
counting the requests. Additionally the check for a valid profile data
pointer can be done earlier to avoid unnecessary locking in a hot path.
CVE-2024-35950:In the Linux kernel, the following vulnerability has been resolved:
drm/client: Fully protect modes[] with dev-&gt;mode_config.mutex
The modes[] array contains pointers to modes on the connectors'
mode lists, which are protected by dev-&gt;mode_config.mutex.
Thus we need to extend modes[] the same protection or by the
time we use it the elements may already be pointing to
freed/reused memory.
CVE-2024-35989:In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix oops during rmmod on single-CPU platforms
During the removal of the idxd driver, registered offline callback is
invoked as part of the clean up process. However, on systems with only
one CPU online, no valid target is available to migrate the
perf context, resulting in a kernel oops:
    BUG: unable to handle page fault for address: 000000000002a2b8
    #PF: supervisor write access in kernel mode
    #PF: error_code(0x0002) - not-present page
    PGD 1470e1067 P4D 0
    Oops: 0002 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 20 Comm: cpuhp/0 Not tainted 6.8.0-rc6-dsa+ #57
    Hardware name: Intel Corporation AvenueCity/AvenueCity, BIOS BHSDCRB1.86B.2492.D03.2307181620 07/18/2023
    RIP: 0010:mutex_lock+0x2e/0x50
    ...
    Call Trace:
    &lt;TASK&gt;
    __die+0x24/0x70
    page_fault_oops+0x82/0x160
    do_user_addr_fault+0x65/0x6b0
    __pfx___rdmsr_safe_on_cpu+0x10/0x10
    exc_page_fault+0x7d/0x170
    asm_exc_page_fault+0x26/0x30
    mutex_lock+0x2e/0x50
    mutex_lock+0x1e/0x50
    perf_pmu_migrate_context+0x87/0x1f0
    perf_event_cpu_offline+0x76/0x90 [idxd]
    cpuhp_invoke_callback+0xa2/0x4f0
    __pfx_perf_event_cpu_offline+0x10/0x10 [idxd]
    cpuhp_thread_fun+0x98/0x150
    smpboot_thread_fn+0x27/0x260
    smpboot_thread_fn+0x1af/0x260
    __pfx_smpboot_thread_fn+0x10/0x10
    kthread+0x103/0x140
    __pfx_kthread+0x10/0x10
    ret_from_fork+0x31/0x50
    __pfx_kthread+0x10/0x10
    ret_from_fork_asm+0x1b/0x30
    &lt;TASK&gt;
Fix the issue by preventing the migration of the perf context to an
invalid target.
CVE-2024-36906:In the Linux kernel, the following vulnerability has been resolved:
ARM: 9381/1: kasan: clear stale stack poison
We found below OOB crash:
[   33.452494] ==================================================================
[   33.453513] BUG: KASAN: stack-out-of-bounds in refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
[   33.454660] Write of size 164 at addr c1d03d30 by task swapper/0/0
[   33.455515]
[   33.455767] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G           O       6.1.25-mainline #1
[   33.456880] Hardware name: Generic DT based system
[   33.457555]  unwind_backtrace from show_stack+0x18/0x1c
[   33.458326]  show_stack from dump_stack_lvl+0x40/0x4c
[   33.459072]  dump_stack_lvl from print_report+0x158/0x4a4
[   33.459863]  print_report from kasan_report+0x9c/0x148
[   33.460616]  kasan_report from kasan_check_range+0x94/0x1a0
[   33.461424]  kasan_check_range from memset+0x20/0x3c
[   33.462157]  memset from refresh_cpu_vm_stats.constprop.0+0xcc/0x2ec
[   33.463064]  refresh_cpu_vm_stats.constprop.0 from tick_nohz_idle_stop_tick+0x180/0x53c
[   33.464181]  tick_nohz_idle_stop_tick from do_idle+0x264/0x354
[   33.465029]  do_idle from cpu_startup_entry+0x20/0x24
[   33.465769]  cpu_startup_entry from rest_init+0xf0/0xf4
[   33.466528]  rest_init from arch_post_acpi_subsys_init+0x0/0x18
[   33.467397]
[   33.467644] The buggy address belongs to stack of task swapper/0/0
[   33.468493]  and is located at offset 112 in frame:
[   33.469172]  refresh_cpu_vm_stats.constprop.0+0x0/0x2ec
[   33.469917]
[   33.470165] This frame has 2 objects:
[   33.470696]  [32, 76) 'global_zone_diff'
[   33.470729]  [112, 276) 'global_node_diff'
[   33.471294]
[   33.472095] The buggy address belongs to the physical page:
[   33.472862] page:3cd72da8 refcount:1 mapcount:0 mapping:00000000 index:0x0 pfn:0x41d03
[   33.473944] flags: 0x1000(reserved|zone=0)
[   33.474565] raw: 00001000 ed741470 ed741470 00000000 00000000 00000000 ffffffff 00000001
[   33.475656] raw: 00000000
[   33.476050] page dumped because: kasan: bad access detected
[   33.476816]
[   33.477061] Memory state around the buggy address:
[   33.477732]  c1d03c00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
[   33.478630]  c1d03c80: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 00 00 00 00
[   33.479526] &gt;c1d03d00: 00 04 f2 f2 f2 f2 00 00 00 00 00 00 f1 f1 f1 f1
[   33.480415]                                                ^
[   33.481195]  c1d03d80: 00 00 00 00 00 00 00 00 00 00 04 f3 f3 f3 f3 f3
[   33.482088]  c1d03e00: f3 f3 f3 f3 00 00 00 00 00 00 00 00 00 00 00 00
[   33.482978] ==================================================================
We find the root cause of this OOB is that arm does not clear stale stack
poison in the case of cpuidle.
This patch refer to arch/arm64/kernel/sleep.S to resolve this issue.
From cited commit [1] that explain the problem
Functions which the compiler has instrumented for KASAN place poison on
the stack shadow upon entry and remove this poison prior to returning.
In the case of cpuidle, CPUs exit the kernel a number of levels deep in
C code.  Any instrumented functions on this critical path will leave
portions of the stack shadow poisoned.
If CPUs lose context and return to the kernel via a cold path, we
restore a prior context saved in __cpu_suspend_enter are forgotten, and
we never remove the poison they placed in the stack shadow area by
functions calls between this and the actual exit of the kernel.
Thus, (depending on stackframe layout) subsequent calls to instrumented
functions may hit this stale poison, resulting in (spurious) KASAN
splats to the console.
To avoid this, clear any stale poison from the idle thread for a CPU
prior to bringing a CPU online.
From cited commit [2]
Extend to check for CONFIG_KASAN_STACK
[1] commit 0d97e6d8024c (&quot;arm64: kasan: clear stale stack poison&quot;)
[2] commit d56a9ef84bd0 (&quot;kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK&quot;)
CVE-2023-52799:In the Linux kernel, the following vulnerability has been resolved:
jfs: fix array-index-out-of-bounds in dbFindLeaf
Currently while searching for dmtree_t for sufficient free blocks there
is an array out of bounds while getting element in tp-&gt;dm_stree. To add
the required check for out of bound we first need to determine the type
of dmtree. Thus added an extra parameter to dbFindLeaf so that the type
of tree can be determined and the required check can be applied.
CVE-2023-52746:In the Linux kernel, the following vulnerability has been resolved:
xfrm/compat: prevent potential spectre v1 gadget in xfrm_xlate32_attr()
  int type = nla_type(nla);
  if (type &gt; XFRMA_MAX) {
            return -EOPNOTSUPP;
  }
@type is then used as an array index and can be used
as a Spectre v1 gadget.
  if (nla_len(nla) &lt; compat_policy[type].len) {
array_index_nospec() can be used to prevent leaking
content of kernel memory to malicious users.
CVE-2021-47558:In the Linux kernel, the following vulnerability has been resolved:
net: stmmac: Disable Tx queues when reconfiguring the interface
The Tx queues were not disabled in situations where the driver needed to
stop the interface to apply a new configuration. This could result in a
kernel panic when doing any of the 3 following actions:
* reconfiguring the number of queues (ethtool -L)
* reconfiguring the size of the ring buffers (ethtool -G)
* installing/removing an XDP program (ip l set dev ethX xdp)
Prevent the panic by making sure netif_tx_disable is called when stopping
an interface.
Without this patch, the following kernel panic can be observed when doing
any of the actions above:
Unable to handle kernel paging request at virtual address ffff80001238d040
[....]
 Call trace:
  dwmac4_set_addr+0x8/0x10
  dev_hard_start_xmit+0xe4/0x1ac
  sch_direct_xmit+0xe8/0x39c
  __dev_queue_xmit+0x3ec/0xaf0
  dev_queue_xmit+0x14/0x20
[...]
[ end trace 0000000000000002 ]---
CVE-2022-48689:In the Linux kernel, the following vulnerability has been resolved:
tcp: TX zerocopy should not sense pfmemalloc status
We got a recent syzbot report [1] showing a possible misuse
of pfmemalloc page status in TCP zerocopy paths.
Indeed, for pages coming from user space or other layers,
using page_is_pfmemalloc() is moot, and possibly could give
false positives.
There has been attempts to make page_is_pfmemalloc() more robust,
but not using it in the first place in this context is probably better,
removing cpu cycles.
Note to stable teams :
You need to backport 84ce071e38a6 (&quot;net: introduce
__skb_fill_page_desc_noacc&quot;) as a prereq.
Race is more probable after commit c07aea3ef4d4
(&quot;mm: add a signature in struct page&quot;) because page_is_pfmemalloc()
is now using low order bit from page-&gt;lru.next, which can change
more often than page-&gt;index.
Low order bit should never be set for lru.next (when used as an anchor
in LRU list), so KCSAN report is mostly a false positive.
Backporting to older kernel versions seems not necessary.
[1]
BUG: KCSAN: data-race in lru_add_fn / tcp_build_frag
write to 0xffffea0004a1d2c8 of 8 bytes by task 18600 on cpu 0:
__list_add include/linux/list.h:73 [inline]
list_add include/linux/list.h:88 [inline]
lruvec_add_folio include/linux/mm_inline.h:105 [inline]
lru_add_fn+0x440/0x520 mm/swap.c:228
folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246
folio_batch_add_and_move mm/swap.c:263 [inline]
folio_add_lru+0xf1/0x140 mm/swap.c:490
filemap_add_folio+0xf8/0x150 mm/filemap.c:948
__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981
pagecache_get_page+0x26/0x190 mm/folio-compat.c:104
grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116
ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988
generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738
ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270
ext4_file_write_iter+0x2e3/0x1210
call_write_iter include/linux/fs.h:2187 [inline]
new_sync_write fs/read_write.c:491 [inline]
vfs_write+0x468/0x760 fs/read_write.c:578
ksys_write+0xe8/0x1a0 fs/read_write.c:631
__do_sys_write fs/read_write.c:643 [inline]
__se_sys_write fs/read_write.c:640 [inline]
__x64_sys_write+0x3e/0x50 fs/read_write.c:640
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
read to 0xffffea0004a1d2c8 of 8 bytes by task 18611 on cpu 1:
page_is_pfmemalloc include/linux/mm.h:1740 [inline]
__skb_fill_page_desc include/linux/skbuff.h:2422 [inline]
skb_fill_page_desc include/linux/skbuff.h:2443 [inline]
tcp_build_frag+0x613/0xb20 net/ipv4/tcp.c:1018
do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075
tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]
tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150
inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833
kernel_sendpage+0x184/0x300 net/socket.c:3561
sock_sendpage+0x5a/0x70 net/socket.c:1054
pipe_to_sendpage+0x128/0x160 fs/splice.c:361
splice_from_pipe_feed fs/splice.c:415 [inline]
__splice_from_pipe+0x222/0x4d0 fs/splice.c:559
splice_from_pipe fs/splice.c:594 [inline]
generic_splice_sendpage+0x89/0xc0 fs/splice.c:743
do_splice_from fs/splice.c:764 [inline]
direct_splice_actor+0x80/0xa0 fs/splice.c:931
splice_direct_to_actor+0x305/0x620 fs/splice.c:886
do_splice_direct+0xfb/0x180 fs/splice.c:974
do_sendfile+0x3bf/0x910 fs/read_write.c:1249
__do_sys_sendfile64 fs/read_write.c:1317 [inline]
__se_sys_sendfile64 fs/read_write.c:1303 [inline]
__x64_sys_sendfile64+0x10c/0x150 fs/read_write.c:1303
do_syscall_x64 arch/x86/entry/common.c:50 [inline]
do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80
entry_SYSCALL_64_after_hwframe+0x63/0xcd
value changed: 0x0000000000000000 -&gt; 0xffffea0004a1d288
Reported by Kernel Concurrency Sanitizer on:
CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022
CVE-2023-52752:In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix use-after-free bug in cifs_debug_data_proc_show()
Skip SMB sessions that are being teared down
(e.g. @ses-&gt;ses_status == SES_EXITING) in cifs_debug_data_proc_show()
to avoid use-after-free in @ses.
This fixes the following GPF when reading from /proc/fs/cifs/DebugData
while mounting and umounting
  [ 816.251274] general protection fault, probably for non-canonical
  address 0x6b6b6b6b6b6b6d81: 0000 [#1] PREEMPT SMP NOPTI
  ...
  [  816.260138] Call Trace:
  [  816.260329]  &lt;TASK&gt;
  [  816.260499]  ? die_addr+0x36/0x90
  [  816.260762]  ? exc_general_protection+0x1b3/0x410
  [  816.261126]  ? asm_exc_general_protection+0x26/0x30
  [  816.261502]  ? cifs_debug_tcon+0xbd/0x240 [cifs]
  [  816.261878]  ? cifs_debug_tcon+0xab/0x240 [cifs]
  [  816.262249]  cifs_debug_data_proc_show+0x516/0xdb0 [cifs]
  [  816.262689]  ? seq_read_iter+0x379/0x470
  [  816.262995]  seq_read_iter+0x118/0x470
  [  816.263291]  proc_reg_read_iter+0x53/0x90
  [  816.263596]  ? srso_alias_return_thunk+0x5/0x7f
  [  816.263945]  vfs_read+0x201/0x350
  [  816.264211]  ksys_read+0x75/0x100
  [  816.264472]  do_syscall_64+0x3f/0x90
  [  816.264750]  entry_SYSCALL_64_after_hwframe+0x6e/0xd8
  [  816.265135] RIP: 0033:0x7fd5e669d381
CVE-2024-35895:In the Linux kernel, the following vulnerability has been resolved:
bpf, sockmap: Prevent lock inversion deadlock in map delete elem
syzkaller started using corpuses where a BPF tracing program deletes
elements from a sockmap/sockhash map. Because BPF tracing programs can be
invoked from any interrupt context, locks taken during a map_delete_elem
operation must be hardirq-safe. Otherwise a deadlock due to lock inversion
is possible, as reported by lockdep:
       CPU0                    CPU1
       ----                    ----
  lock(&amp;htab-&gt;buckets[i].lock);
                               local_irq_disable();
                               lock(&amp;host-&gt;lock);
                               lock(&amp;htab-&gt;buckets[i].lock);
  &lt;Interrupt&gt;
    lock(&amp;host-&gt;lock);
Locks in sockmap are hardirq-unsafe by design. We expects elements to be
deleted from sockmap/sockhash only in task (normal) context with interrupts
enabled, or in softirq context.
Detect when map_delete_elem operation is invoked from a context which is
_not_ hardirq-unsafe, that is interrupts are disabled, and bail out with an
error.
Note that map updates are not affected by this issue. BPF verifier does not
allow updating sockmap/sockhash from a BPF tracing program today.
CVE-2024-35896:In the Linux kernel, the following vulnerability has been resolved:
netfilter: validate user input for expected length
I got multiple syzbot reports showing old bugs exposed
by BPF after commit 20f2505fb436 (&quot;bpf: Try to avoid kzalloc
in cgroup/{s,g}etsockopt&quot;)
setsockopt() @optlen argument should be taken into account
before copying data.
 BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
 BUG: KASAN: slab-out-of-bounds in copy_from_sockptr include/linux/sockptr.h:55 [inline]
 BUG: KASAN: slab-out-of-bounds in do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
 BUG: KASAN: slab-out-of-bounds in do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238
CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  print_address_description mm/kasan/report.c:377 [inline]
  print_report+0x169/0x550 mm/kasan/report.c:488
  kasan_report+0x143/0x180 mm/kasan/report.c:601
  kasan_check_range+0x282/0x290 mm/kasan/generic.c:189
  __asan_memcpy+0x29/0x70 mm/kasan/shadow.c:105
  copy_from_sockptr_offset include/linux/sockptr.h:49 [inline]
  copy_from_sockptr include/linux/sockptr.h:55 [inline]
  do_replace net/ipv4/netfilter/ip_tables.c:1111 [inline]
  do_ipt_set_ctl+0x902/0x3dd0 net/ipv4/netfilter/ip_tables.c:1627
  nf_setsockopt+0x295/0x2c0 net/netfilter/nf_sockopt.c:101
  do_sock_setsockopt+0x3af/0x720 net/socket.c:2311
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x72/0x7a
RIP: 0033:0x7fd22067dde9
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
RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9
RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003
RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000
R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000
R13: 000000000000000b R14: 00007fd2207abf80 R15: 00007ffd2d0170d8
 &lt;/TASK&gt;
Allocated by task 7238:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  poison_kmalloc_redzone mm/kasan/common.c:370 [inline]
  __kasan_kmalloc+0x98/0xb0 mm/kasan/common.c:387
  kasan_kmalloc include/linux/kasan.h:211 [inline]
  __do_kmalloc_node mm/slub.c:4069 [inline]
  __kmalloc_noprof+0x200/0x410 mm/slub.c:4082
  kmalloc_noprof include/linux/slab.h:664 [inline]
  __cgroup_bpf_run_filter_setsockopt+0xd47/0x1050 kernel/bpf/cgroup.c:1869
  do_sock_setsockopt+0x6b4/0x720 net/socket.c:2293
  __sys_setsockopt+0x1ae/0x250 net/socket.c:2334
  __do_sys_setsockopt net/socket.c:2343 [inline]
  __se_sys_setsockopt net/socket.c:2340 [inline]
  __x64_sys_setsockopt+0xb5/0xd0 net/socket.c:2340
 do_syscall_64+0xfb/0x240
 entry_SYSCALL_64_after_hwframe+0x72/0x7a
The buggy address belongs to the object at ffff88802cd73da0
 which belongs to the cache kmalloc-8 of size 8
The buggy address is located 0 bytes inside of
 allocated 1-byte region [ffff88802cd73da0, ffff88802cd73da1)
The buggy address belongs to the physical page:
page: refcount:1 mapcount:0 mapping:0000000000000000 index:0xffff88802cd73020 pfn:0x2cd73
flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)
page_type: 0xffffefff(slab)
raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122
raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00
---truncated---
CVE-2024-36964:In the Linux kernel, the following vulnerability has been resolved:
fs/9p: only translate RWX permissions for plain 9P2000
Garbage in plain 9P2000's perm bits is allowed through, which causes it
to be able to set (among others) the suid bit. This was presumably not
the intent since the unix extended bits are handled explicitly and
conditionally on .u.
CVE-2024-27399:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeout
There is a race condition between l2cap_chan_timeout() and
l2cap_chan_del(). When we use l2cap_chan_del() to delete the
channel, the chan-&gt;conn will be set to null. But the conn could
be dereferenced again in the mutex_lock() of l2cap_chan_timeout().
As a result the null pointer dereference bug will happen. The
KASAN report triggered by POC is shown below:
[  472.074580] ==================================================================
[  472.075284] BUG: KASAN: null-ptr-deref in mutex_lock+0x68/0xc0
[  472.075308] Write of size 8 at addr 0000000000000158 by task kworker/0:0/7
[  472.075308]
[  472.075308] CPU: 0 PID: 7 Comm: kworker/0:0 Not tainted 6.9.0-rc5-00356-g78c0094a146b #36
[  472.075308] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
[  472.075308] Workqueue: events l2cap_chan_timeout
[  472.075308] Call Trace:
[  472.075308]  &lt;TASK&gt;
[  472.075308]  dump_stack_lvl+0x137/0x1a0
[  472.075308]  print_report+0x101/0x250
[  472.075308]  ? __virt_addr_valid+0x77/0x160
[  472.075308]  ? mutex_lock+0x68/0xc0
[  472.075308]  kasan_report+0x139/0x170
[  472.075308]  ? mutex_lock+0x68/0xc0
[  472.075308]  kasan_check_range+0x2c3/0x2e0
[  472.075308]  mutex_lock+0x68/0xc0
[  472.075308]  l2cap_chan_timeout+0x181/0x300
[  472.075308]  process_one_work+0x5d2/0xe00
[  472.075308]  worker_thread+0xe1d/0x1660
[  472.075308]  ? pr_cont_work+0x5e0/0x5e0
[  472.075308]  kthread+0x2b7/0x350
[  472.075308]  ? pr_cont_work+0x5e0/0x5e0
[  472.075308]  ? kthread_blkcg+0xd0/0xd0
[  472.075308]  ret_from_fork+0x4d/0x80
[  472.075308]  ? kthread_blkcg+0xd0/0xd0
[  472.075308]  ret_from_fork_asm+0x11/0x20
[  472.075308]  &lt;/TASK&gt;
[  472.075308] ==================================================================
[  472.094860] Disabling lock debugging due to kernel taint
[  472.096136] BUG: kernel NULL pointer dereference, address: 0000000000000158
[  472.096136] #PF: supervisor write access in kernel mode
[  472.096136] #PF: error_code(0x0002) - not-present page
[  472.096136] PGD 0 P4D 0
[  472.096136] Oops: 0002 [#1] PREEMPT SMP KASAN NOPTI
[  472.096136] CPU: 0 PID: 7 Comm: kworker/0:0 Tainted: G    B              6.9.0-rc5-00356-g78c0094a146b #36
[  472.096136] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu4
[  472.096136] Workqueue: events l2cap_chan_timeout
[  472.096136] RIP: 0010:mutex_lock+0x88/0xc0
[  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
[  472.096136] RSP: 0018:ffff88800744fc78 EFLAGS: 00000246
[  472.096136] RAX: 0000000000000000 RBX: 1ffff11000e89f8f RCX: ffffffff8457c865
[  472.096136] RDX: 0000000000000001 RSI: 0000000000000008 RDI: ffff88800744fc78
[  472.096136] RBP: 0000000000000158 R08: ffff88800744fc7f R09: 1ffff11000e89f8f
[  472.096136] R10: dffffc0000000000 R11: ffffed1000e89f90 R12: dffffc0000000000
[  472.096136] R13: 0000000000000158 R14: ffff88800744fc78 R15: ffff888007405a00
[  472.096136] FS:  0000000000000000(0000) GS:ffff88806d200000(0000) knlGS:0000000000000000
[  472.096136] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  472.096136] CR2: 0000000000000158 CR3: 000000000da32000 CR4: 00000000000006f0
[  472.096136] Call Trace:
[  472.096136]  &lt;TASK&gt;
[  472.096136]  ? __die_body+0x8d/0xe0
[  472.096136]  ? page_fault_oops+0x6b8/0x9a0
[  472.096136]  ? kernelmode_fixup_or_oops+0x20c/0x2a0
[  472.096136]  ? do_user_addr_fault+0x1027/0x1340
[  472.096136]  ? _printk+0x7a/0xa0
[  472.096136]  ? mutex_lock+0x68/0xc0
[  472.096136]  ? add_taint+0x42/0xd0
[  472.096136]  ? exc_page_fault+0x6a/0x1b0
[  472.096136]  ? asm_exc_page_fault+0x26/0x30
[  472.096136]  ? mutex_lock+0x75/0xc0
[  472.096136]  ? mutex_lock+0x88/0xc0
[  472.096136]  ? mutex_lock+0x75/0xc0
[  472.096136]  l2cap_chan_timeo
---truncated---
CVE-2024-35855:In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity update
The rule activity update delayed work periodically traverses the list of
configured rules and queries their activity from the device.
As part of this task it accesses the entry pointed by 'ventry-&gt;entry',
but this entry can be changed concurrently by the rehash delayed work,
leading to a use-after-free [1].
Fix by closing the race and perform the activity query under the
'vregion-&gt;lock' mutex.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181
CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0xc6/0x120
 print_report+0xce/0x670
 kasan_report+0xd7/0x110
 mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140
 mlxsw_sp_acl_rule_activity_update_work+0x219/0x400
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
Allocated by task 1039:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x8f/0xa0
 __kmalloc+0x19c/0x360
 mlxsw_sp_acl_tcam_entry_create+0x7b/0x1f0
 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x30d/0xb50
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30
Freed by task 1039:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 poison_slab_object+0x102/0x170
 __kasan_slab_free+0x14/0x30
 kfree+0xc1/0x290
 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3d7/0xb50
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30
CVE-2024-35888:In the Linux kernel, the following vulnerability has been resolved:
erspan: make sure erspan_base_hdr is present in skb-&gt;head
syzbot reported a problem in ip6erspan_rcv() [1]
Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer make
sure erspan_base_hdr is present in skb linear part (skb-&gt;head)
before getting @ver field from it.
Add the missing pskb_may_pull() calls.
v2: Reload iph pointer in erspan_rcv() after pskb_may_pull()
    because skb-&gt;head might have changed.
[1]
 BUG: KMSAN: uninit-value in pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
 BUG: KMSAN: uninit-value in pskb_may_pull include/linux/skbuff.h:2756 [inline]
 BUG: KMSAN: uninit-value in ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
 BUG: KMSAN: uninit-value in gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
  pskb_may_pull_reason include/linux/skbuff.h:2742 [inline]
  pskb_may_pull include/linux/skbuff.h:2756 [inline]
  ip6erspan_rcv net/ipv6/ip6_gre.c:541 [inline]
  gre_rcv+0x11f8/0x1930 net/ipv6/ip6_gre.c:610
  ip6_protocol_deliver_rcu+0x1d4c/0x2ca0 net/ipv6/ip6_input.c:438
  ip6_input_finish net/ipv6/ip6_input.c:483 [inline]
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_input+0x15d/0x430 net/ipv6/ip6_input.c:492
  ip6_mc_input+0xa7e/0xc80 net/ipv6/ip6_input.c:586
  dst_input include/net/dst.h:460 [inline]
  ip6_rcv_finish+0x955/0x970 net/ipv6/ip6_input.c:79
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ipv6_rcv+0xde/0x390 net/ipv6/ip6_input.c:310
  __netif_receive_skb_one_core net/core/dev.c:5538 [inline]
  __netif_receive_skb+0x1da/0xa00 net/core/dev.c:5652
  netif_receive_skb_internal net/core/dev.c:5738 [inline]
  netif_receive_skb+0x58/0x660 net/core/dev.c:5798
  tun_rx_batched+0x3ee/0x980 drivers/net/tun.c:1549
  tun_get_user+0x5566/0x69e0 drivers/net/tun.c:2002
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
  call_write_iter include/linux/fs.h:2108 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0xb63/0x1520 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xe0 fs/read_write.c:652
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3804 [inline]
  slab_alloc_node mm/slub.c:3845 [inline]
  kmem_cache_alloc_node+0x613/0xc50 mm/slub.c:3888
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:577
  __alloc_skb+0x35b/0x7a0 net/core/skbuff.c:668
  alloc_skb include/linux/skbuff.h:1318 [inline]
  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
  tun_alloc_skb drivers/net/tun.c:1525 [inline]
  tun_get_user+0x209a/0x69e0 drivers/net/tun.c:1846
  tun_chr_write_iter+0x3af/0x5d0 drivers/net/tun.c:2048
  call_write_iter include/linux/fs.h:2108 [inline]
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0xb63/0x1520 fs/read_write.c:590
  ksys_write+0x20f/0x4c0 fs/read_write.c:643
  __do_sys_write fs/read_write.c:655 [inline]
  __se_sys_write fs/read_write.c:652 [inline]
  __x64_sys_write+0x93/0xe0 fs/read_write.c:652
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0
CVE-2023-52677:In the Linux kernel, the following vulnerability has been resolved:
riscv: Check if the code to patch lies in the exit section
Otherwise we fall through to vmalloc_to_page() which panics since the
address does not lie in the vmalloc region.
CVE-2023-52800:In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix htt pktlog locking
The ath11k active pdevs are protected by RCU but the htt pktlog handling
code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid
any potential use-after-free issues.
Compile tested only.
CVE-2024-35790:In the Linux kernel, the following vulnerability has been resolved:
usb: typec: altmodes/displayport: create sysfs nodes as driver's default device attribute group
The DisplayPort driver's sysfs nodes may be present to the userspace before
typec_altmode_set_drvdata() completes in dp_altmode_probe. This means that
a sysfs read can trigger a NULL pointer error by deferencing dp-&gt;hpd in
hpd_show or dp-&gt;lock in pin_assignment_show, as dev_get_drvdata() returns
NULL in those cases.
Remove manual sysfs node creation in favor of adding attribute group as
default for devices bound to the driver. The ATTRIBUTE_GROUPS() macro is
not used here otherwise the path to the sysfs nodes is no longer compliant
with the ABI.
CVE-2024-27402:In the Linux kernel, the following vulnerability has been resolved:
phonet/pep: fix racy skb_queue_empty() use
The receive queues are protected by their respective spin-lock, not
the socket lock. This could lead to skb_peek() unexpectedly
returning NULL or a pointer to an already dequeued socket buffer.
CVE-2023-52798:In the Linux kernel, the following vulnerability has been resolved:
wifi: ath11k: fix dfs radar event locking
The ath11k active pdevs are protected by RCU but the DFS radar event
handling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as a
read-side critical section.
Mark the code in question as an RCU read-side critical section to avoid
any potential use-after-free issues.
Compile tested only.
CVE-2024-35854:In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehash
The rehash delayed work migrates filters from one region to another
according to the number of available credits.
The migrated from region is destroyed at the end of the work if the
number of credits is non-negative as the assumption is that this is
indicative of migration being complete. This assumption is incorrect as
a non-negative number of credits can also be the result of a failed
migration.
The destruction of a region that still has filters referencing it can
result in a use-after-free [1].
Fix by not destroying the region if migration failed.
[1]
BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858
CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G        W          6.9.0-rc2-custom-00782-gf2275c2157d8 #5
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0xc6/0x120
 print_report+0xce/0x670
 kasan_report+0xd7/0x110
 mlxsw_sp_acl_ctcam_region_entry_remove+0x21d/0x230
 mlxsw_sp_acl_ctcam_entry_del+0x2e/0x70
 mlxsw_sp_acl_atcam_entry_del+0x81/0x210
 mlxsw_sp_acl_tcam_vchunk_migrate_all+0x3cd/0xb50
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x157/0x1300
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
Allocated by task 174:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 __kasan_kmalloc+0x8f/0xa0
 __kmalloc+0x19c/0x360
 mlxsw_sp_acl_tcam_region_create+0xdf/0x9c0
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x954/0x1300
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30
Freed by task 7:
 kasan_save_stack+0x33/0x60
 kasan_save_track+0x14/0x30
 kasan_save_free_info+0x3b/0x60
 poison_slab_object+0x102/0x170
 __kasan_slab_free+0x14/0x30
 kfree+0xc1/0x290
 mlxsw_sp_acl_tcam_region_destroy+0x272/0x310
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x731/0x1300
 process_one_work+0x8eb/0x19b0
 worker_thread+0x6c9/0xf70
 kthread+0x2c9/0x3b0
 ret_from_fork+0x4d/0x80
 ret_from_fork_asm+0x1a/0x30
CVE-2024-36021:In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during pf initialization
The devlink reload process will access the hardware resources,
but the register operation is done before the hardware is initialized.
So, processing the devlink reload during initialization may lead to kernel
crash. This patch fixes this by taking devl_lock during initialization.
CVE-2024-36900:In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix kernel crash when devlink reload during initialization
The devlink reload process will access the hardware resources,
but the register operation is done before the hardware is initialized.
So, processing the devlink reload during initialization may lead to kernel
crash.
This patch fixes this by registering the devlink after
hardware initialization.
CVE-2024-36017:In the Linux kernel, the following vulnerability has been resolved:
rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validation
Each attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be a
struct ifla_vf_vlan_info so the size of such attribute needs to be at least
of sizeof(struct ifla_vf_vlan_info) which is 14 bytes.
The current size validation in do_setvfinfo is against NLA_HDRLEN (4 bytes)
which is less than sizeof(struct ifla_vf_vlan_info) so this validation
is not enough and a too small attribute might be cast to a
struct ifla_vf_vlan_info, this might result in an out of bands
read access when accessing the saved (casted) entry in ivvl.
CVE-2024-35853:In the Linux kernel, the following vulnerability has been resolved:
mlxsw: spectrum_acl_tcam: Fix memory leak during rehash
The rehash delayed work migrates filters from one region to another.
This is done by iterating over all chunks (all the filters with the same
priority) in the region and in each chunk iterating over all the
filters.
If the migration fails, the code tries to migrate the filters back to
the old region. However, the rollback itself can also fail in which case
another migration will be erroneously performed. Besides the fact that
this ping pong is not a very good idea, it also creates a problem.
Each virtual chunk references two chunks: The currently used one
('vchunk-&gt;chunk') and a backup ('vchunk-&gt;chunk2'). During migration the
first holds the chunk we want to migrate filters to and the second holds
the chunk we are migrating filters from.
The code currently assumes - but does not verify - that the backup chunk
does not exist (NULL) if the currently used chunk does not reference the
target region. This assumption breaks when we are trying to rollback a
rollback, resulting in the backup chunk being overwritten and leaked
[1].
Fix by not rolling back a failed rollback and add a warning to avoid
future cases.
[1]
WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20
Modules linked in:
CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G        W          6.9.0-rc2-custom-00784-gc6a05c468a0b #14
Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019
Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_work
RIP: 0010:parman_destroy+0x17/0x20
[...]
Call Trace:
 &lt;TASK&gt;
 mlxsw_sp_acl_atcam_region_fini+0x19/0x60
 mlxsw_sp_acl_tcam_region_destroy+0x49/0xf0
 mlxsw_sp_acl_tcam_vregion_rehash_work+0x1f1/0x470
 process_one_work+0x151/0x370
 worker_thread+0x2cb/0x3e0
 kthread+0xd0/0x100
 ret_from_fork+0x34/0x50
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
CVE-2024-35910:In the Linux kernel, the following vulnerability has been resolved:
tcp: properly terminate timers for kernel sockets
We had various syzbot reports about tcp timers firing after
the corresponding netns has been dismantled.
Fortunately Josef Bacik could trigger the issue more often,
and could test a patch I wrote two years ago.
When TCP sockets are closed, we call inet_csk_clear_xmit_timers()
to 'stop' the timers.
inet_csk_clear_xmit_timers() can be called from any context,
including when socket lock is held.
This is the reason it uses sk_stop_timer(), aka del_timer().
This means that ongoing timers might finish much later.
For user sockets, this is fine because each running timer
holds a reference on the socket, and the user socket holds
a reference on the netns.
For kernel sockets, we risk that the netns is freed before
timer can complete, because kernel sockets do not hold
reference on the netns.
This patch adds inet_csk_clear_xmit_timers_sync() function
that using sk_stop_timer_sync() to make sure all timers
are terminated before the kernel socket is released.
Modules using kernel sockets close them in their netns exit()
handler.
Also add sock_not_owned_by_me() helper to get LOCKDEP
support : inet_csk_clear_xmit_timers_sync() must not be called
while socket lock is held.
It is very possible we can revert in the future commit
3a58f13a881e (&quot;net: rds: acquire refcount on TCP sockets&quot;)
which attempted to solve the issue in rds only.
(net/smc/af_smc.c and net/mptcp/subflow.c have similar code)
We probably can remove the check_net() tests from
tcp_out_of_resources() and __tcp_close() in the future.
CVE-2024-35937:In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: check A-MSDU format more carefully
If it looks like there's another subframe in the A-MSDU
but the header isn't fully there, we can end up reading
data out of bounds, only to discard later. Make this a
bit more careful and check if the subframe header can
even be present.
CVE-2024-35925:In the Linux kernel, the following vulnerability has been resolved:
block: prevent division by zero in blk_rq_stat_sum()
The expression dst-&gt;nr_samples + src-&gt;nr_samples may
have zero value on overflow. It is necessary to add
a check to avoid division by zero.
Found by Linux Verification Center (linuxtesting.org) with Svace.
CVE-2024-35821:In the Linux kernel, the following vulnerability has been resolved:
ubifs: Set page uptodate in the correct place
Page cache reads are lockless, so setting the freshly allocated page
uptodate before we've overwritten it with the data it's supposed to have
in it will allow a simultaneous reader to see old data.  Move the call
to SetPageUptodate into ubifs_write_end(), which is after we copied the
new data into the page.
CVE-2024-36029:In the Linux kernel, the following vulnerability has been resolved:
mmc: sdhci-msm: pervent access to suspended controller
Generic sdhci code registers LED device and uses host-&gt;runtime_suspended
flag to protect access to it. The sdhci-msm driver doesn't set this flag,
which causes a crash when LED is accessed while controller is runtime
suspended. Fix this by setting the flag correctly.
CVE-2023-52739:In the Linux kernel, the following vulnerability has been resolved:
Fix page corruption caused by racy check in __free_pages
When we upgraded our kernel, we started seeing some page corruption like
the following consistently:
  BUG: Bad page state in process ganesha.nfsd  pfn:1304ca
  page:0000000022261c55 refcount:0 mapcount:-128 mapping:0000000000000000 index:0x0 pfn:0x1304ca
  flags: 0x17ffffc0000000()
  raw: 0017ffffc0000000 ffff8a513ffd4c98 ffffeee24b35ec08 0000000000000000
  raw: 0000000000000000 0000000000000001 00000000ffffff7f 0000000000000000
  page dumped because: nonzero mapcount
  CPU: 0 PID: 15567 Comm: ganesha.nfsd Kdump: loaded Tainted: P    B      O      5.10.158-1.nutanix.20221209.el7.x86_64 #1
  Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 04/05/2016
  Call Trace:
   dump_stack+0x74/0x96
   bad_page.cold+0x63/0x94
   check_new_page_bad+0x6d/0x80
   rmqueue+0x46e/0x970
   get_page_from_freelist+0xcb/0x3f0
   ? _cond_resched+0x19/0x40
   __alloc_pages_nodemask+0x164/0x300
   alloc_pages_current+0x87/0xf0
   skb_page_frag_refill+0x84/0x110
   ...
Sometimes, it would also show up as corruption in the free list pointer
and cause crashes.
After bisecting the issue, we found the issue started from commit
e320d3012d25 (&quot;mm/page_alloc.c: fix freeing non-compound pages&quot;):
	if (put_page_testzero(page))
		free_the_page(page, order);
	else if (!PageHead(page))
		while (order-- &gt; 0)
			free_the_page(page + (1 &lt;&lt; order), order);
So the problem is the check PageHead is racy because at this point we
already dropped our reference to the page.  So even if we came in with
compound page, the page can already be freed and PageHead can return
false and we will end up freeing all the tail pages causing double free.
CVE-2024-35887:In the Linux kernel, the following vulnerability has been resolved:
ax25: fix use-after-free bugs caused by ax25_ds_del_timer
When the ax25 device is detaching, the ax25_dev_device_down()
calls ax25_ds_del_timer() to cleanup the slave_timer. When
the timer handler is running, the ax25_ds_del_timer() that
calls del_timer() in it will return directly. As a result,
the use-after-free bugs could happen, one of the scenarios
is shown below:
      (Thread 1)          |      (Thread 2)
                          | ax25_ds_timeout()
ax25_dev_device_down()    |
  ax25_ds_del_timer()     |
    del_timer()           |
  ax25_dev_put() //FREE   |
                          |  ax25_dev-&gt; //USE
In order to mitigate bugs, when the device is detaching, use
timer_shutdown_sync() to stop the timer.
CVE-2024-36904:In the Linux kernel, the following vulnerability has been resolved:
tcp: Use refcount_inc_not_zero() in tcp_twsk_unique().
Anderson Nascimento reported a use-after-free splat in tcp_twsk_unique()
with nice analysis.
Since commit ec94c2696f0b (&quot;tcp/dccp: avoid one atomic operation for
timewait hashdance&quot;), inet_twsk_hashdance() sets TIME-WAIT socket's
sk_refcnt after putting it into ehash and releasing the bucket lock.
Thus, there is a small race window where other threads could try to
reuse the port during connect() and call sock_hold() in tcp_twsk_unique()
for the TIME-WAIT socket with zero refcnt.
If that happens, the refcnt taken by tcp_twsk_unique() is overwritten
and sock_put() will cause underflow, triggering a real use-after-free
somewhere else.
To avoid the use-after-free, we need to use refcount_inc_not_zero() in
tcp_twsk_unique() and give up on reusing the port if it returns false.
[0]:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 0 PID: 1039313 at lib/refcount.c:25 refcount_warn_saturate+0xe5/0x110
CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1
Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023
RIP: 0010:refcount_warn_saturate+0xe5/0x110
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
RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282
RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027
RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0
RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0
R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84
R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0
FS:  00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? refcount_warn_saturate+0xe5/0x110
 ? __warn+0x81/0x130
 ? refcount_warn_saturate+0xe5/0x110
 ? report_bug+0x171/0x1a0
 ? refcount_warn_saturate+0xe5/0x110
 ? handle_bug+0x3c/0x80
 ? exc_invalid_op+0x17/0x70
 ? asm_exc_invalid_op+0x1a/0x20
 ? refcount_warn_saturate+0xe5/0x110
 tcp_twsk_unique+0x186/0x190
 __inet_check_established+0x176/0x2d0
 __inet_hash_connect+0x74/0x7d0
 ? __pfx___inet_check_established+0x10/0x10
 tcp_v4_connect+0x278/0x530
 __inet_stream_connect+0x10f/0x3d0
 inet_stream_connect+0x3a/0x60
 __sys_connect+0xa8/0xd0
 __x64_sys_connect+0x18/0x20
 do_syscall_64+0x83/0x170
 entry_SYSCALL_64_after_hwframe+0x78/0x80
RIP: 0033:0x7f62c11a885d
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
RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002a
RAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885d
RDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003
RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0
R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0
 &lt;/TASK&gt;
CVE-2024-36889:In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure snd_nxt is properly initialized on connect
Christoph reported a splat hinting at a corrupted snd_una:
  WARNING: CPU: 1 PID: 38 at net/mptcp/protocol.c:1005 __mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
  Modules linked in:
  CPU: 1 PID: 38 Comm: kworker/1:1 Not tainted 6.9.0-rc1-gbbeac67456c9 #59
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014
  Workqueue: events mptcp_worker
  RIP: 0010:__mptcp_clean_una+0x4b3/0x620 net/mptcp/protocol.c:1005
  Code: be 06 01 00 00 bf 06 01 00 00 e8 a8 12 e7 fe e9 00 fe ff ff e8
  	8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe
  	&lt;0f&gt; 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9
  RSP: 0018:ffffc9000013fd48 EFLAGS: 00010293
  RAX: 0000000000000000 RBX: ffff8881029bd280 RCX: ffffffff82382fe4
  RDX: ffff8881003cbd00 RSI: ffffffff823833c3 RDI: 0000000000000001
  RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
  R10: 0000000000000000 R11: fefefefefefefeff R12: ffff888138ba8000
  R13: 0000000000000106 R14: ffff8881029bd908 R15: ffff888126560000
  FS:  0000000000000000(0000) GS:ffff88813bd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f604a5dae38 CR3: 0000000101dac002 CR4: 0000000000170ef0
  Call Trace:
   &lt;TASK&gt;
   __mptcp_clean_una_wakeup net/mptcp/protocol.c:1055 [inline]
   mptcp_clean_una_wakeup net/mptcp/protocol.c:1062 [inline]
   __mptcp_retrans+0x7f/0x7e0 net/mptcp/protocol.c:2615
   mptcp_worker+0x434/0x740 net/mptcp/protocol.c:2767
   process_one_work+0x1e0/0x560 kernel/workqueue.c:3254
   process_scheduled_works kernel/workqueue.c:3335 [inline]
   worker_thread+0x3c7/0x640 kernel/workqueue.c:3416
   kthread+0x121/0x170 kernel/kthread.c:388
   ret_from_fork+0x44/0x50 arch/x86/kernel/process.c:147
   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:243
   &lt;/TASK&gt;
When fallback to TCP happens early on a client socket, snd_nxt
is not yet initialized and any incoming ack will copy such value
into snd_una. If the mptcp worker (dumbly) tries mptcp-level
re-injection after such ack, that would unconditionally trigger a send
buffer cleanup using 'bad' snd_una values.
We could easily disable re-injection for fallback sockets, but such
dumb behavior already helped catching a few subtle issues and a very
low to zero impact in practice.
Instead address the issue always initializing snd_nxt (and write_seq,
for consistency) at connect time.
CVE-2024-36957:In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: avoid off-by-one read from userspace
We try to access count + 1 byte from userspace with memdup_user(buffer,
count + 1). However, the userspace only provides buffer of count bytes and
only these count bytes are verified to be okay to access. To ensure the
copied buffer is NUL terminated, we use memdup_user_nul instead.
CVE-2023-52756:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-36886:In the Linux kernel, the following vulnerability has been resolved:
tipc: fix UAF in error path
Sam Page (sam4k) working with Trend Micro Zero Day Initiative reported
a UAF in the tipc_buf_append() error path:
BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0
linux/net/core/skbuff.c:1183
Read of size 8 at addr ffff88804d2a7c80 by task poc/8034
CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
1.16.0-debian-1.16.0-5 04/01/2014
Call Trace:
 &lt;IRQ&gt;
 __dump_stack linux/lib/dump_stack.c:88
 dump_stack_lvl+0xd9/0x1b0 linux/lib/dump_stack.c:106
 print_address_description linux/mm/kasan/report.c:377
 print_report+0xc4/0x620 linux/mm/kasan/report.c:488
 kasan_report+0xda/0x110 linux/mm/kasan/report.c:601
 kfree_skb_list_reason+0x47e/0x4c0 linux/net/core/skbuff.c:1183
 skb_release_data+0x5af/0x880 linux/net/core/skbuff.c:1026
 skb_release_all linux/net/core/skbuff.c:1094
 __kfree_skb linux/net/core/skbuff.c:1108
 kfree_skb_reason+0x12d/0x210 linux/net/core/skbuff.c:1144
 kfree_skb linux/./include/linux/skbuff.h:1244
 tipc_buf_append+0x425/0xb50 linux/net/tipc/msg.c:186
 tipc_link_input+0x224/0x7c0 linux/net/tipc/link.c:1324
 tipc_link_rcv+0x76e/0x2d70 linux/net/tipc/link.c:1824
 tipc_rcv+0x45f/0x10f0 linux/net/tipc/node.c:2159
 tipc_udp_recv+0x73b/0x8f0 linux/net/tipc/udp_media.c:390
 udp_queue_rcv_one_skb+0xad2/0x1850 linux/net/ipv4/udp.c:2108
 udp_queue_rcv_skb+0x131/0xb00 linux/net/ipv4/udp.c:2186
 udp_unicast_rcv_skb+0x165/0x3b0 linux/net/ipv4/udp.c:2346
 __udp4_lib_rcv+0x2594/0x3400 linux/net/ipv4/udp.c:2422
 ip_protocol_deliver_rcu+0x30c/0x4e0 linux/net/ipv4/ip_input.c:205
 ip_local_deliver_finish+0x2e4/0x520 linux/net/ipv4/ip_input.c:233
 NF_HOOK linux/./include/linux/netfilter.h:314
 NF_HOOK linux/./include/linux/netfilter.h:308
 ip_local_deliver+0x18e/0x1f0 linux/net/ipv4/ip_input.c:254
 dst_input linux/./include/net/dst.h:461
 ip_rcv_finish linux/net/ipv4/ip_input.c:449
 NF_HOOK linux/./include/linux/netfilter.h:314
 NF_HOOK linux/./include/linux/netfilter.h:308
 ip_rcv+0x2c5/0x5d0 linux/net/ipv4/ip_input.c:569
 __netif_receive_skb_one_core+0x199/0x1e0 linux/net/core/dev.c:5534
 __netif_receive_skb+0x1f/0x1c0 linux/net/core/dev.c:5648
 process_backlog+0x101/0x6b0 linux/net/core/dev.c:5976
 __napi_poll.constprop.0+0xba/0x550 linux/net/core/dev.c:6576
 napi_poll linux/net/core/dev.c:6645
 net_rx_action+0x95a/0xe90 linux/net/core/dev.c:6781
 __do_softirq+0x21f/0x8e7 linux/kernel/softirq.c:553
 do_softirq linux/kernel/softirq.c:454
 do_softirq+0xb2/0xf0 linux/kernel/softirq.c:441
 &lt;/IRQ&gt;
 &lt;TASK&gt;
 __local_bh_enable_ip+0x100/0x120 linux/kernel/softirq.c:381
 local_bh_enable linux/./include/linux/bottom_half.h:33
 rcu_read_unlock_bh linux/./include/linux/rcupdate.h:851
 __dev_queue_xmit+0x871/0x3ee0 linux/net/core/dev.c:4378
 dev_queue_xmit linux/./include/linux/netdevice.h:3169
 neigh_hh_output linux/./include/net/neighbour.h:526
 neigh_output linux/./include/net/neighbour.h:540
 ip_finish_output2+0x169f/0x2550 linux/net/ipv4/ip_output.c:235
 __ip_finish_output linux/net/ipv4/ip_output.c:313
 __ip_finish_output+0x49e/0x950 linux/net/ipv4/ip_output.c:295
 ip_finish_output+0x31/0x310 linux/net/ipv4/ip_output.c:323
 NF_HOOK_COND linux/./include/linux/netfilter.h:303
 ip_output+0x13b/0x2a0 linux/net/ipv4/ip_output.c:433
 dst_output linux/./include/net/dst.h:451
 ip_local_out linux/net/ipv4/ip_output.c:129
 ip_send_skb+0x3e5/0x560 linux/net/ipv4/ip_output.c:1492
 udp_send_skb+0x73f/0x1530 linux/net/ipv4/udp.c:963
 udp_sendmsg+0x1a36/0x2b40 linux/net/ipv4/udp.c:1250
 inet_sendmsg+0x105/0x140 linux/net/ipv4/af_inet.c:850
 sock_sendmsg_nosec linux/net/socket.c:730
 __sock_sendmsg linux/net/socket.c:745
 __sys_sendto+0x42c/0x4e0 linux/net/socket.c:2191
 __do_sys_sendto linux/net/socket.c:2203
 __se_sys_sendto linux/net/socket.c:2199
 __x64_sys_sendto+0xe0/0x1c0 linux/net/socket.c:2199
 do_syscall_x64 linux/arch/x86/entry/common.c:52
 do_syscall_
---truncated---
CVE-2024-35870:In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix UAF in smb2_reconnect_server()
The UAF bug is due to smb2_reconnect_server() accessing a session that
is already being teared down by another thread that is executing
__cifs_put_smb_ses().  This can happen when (a) the client has
connection to the server but no session or (b) another thread ends up
setting @ses-&gt;ses_status again to something different than
SES_EXITING.
To fix this, we need to make sure to unconditionally set
@ses-&gt;ses_status to SES_EXITING and prevent any other threads from
setting a new status while we're still tearing it down.
The following can be reproduced by adding some delay to right after
the ipc is freed in __cifs_put_smb_ses() - which will give
smb2_reconnect_server() worker a chance to run and then accessing
@ses-&gt;ipc:
kinit ...
mount.cifs //srv/share /mnt/1 -o sec=krb5,nohandlecache,echo_interval=10
[disconnect srv]
ls /mnt/1 &amp;&gt;/dev/null
sleep 30
kdestroy
[reconnect srv]
sleep 10
umount /mnt/1
...
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
CIFS: VFS: Verify user has a krb5 ticket and keyutils is installed
CIFS: VFS: \\srv Send error in SessSetup = -126
general protection fault, probably for non-canonical address
0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc39
04/01/2014
Workqueue: cifsiod smb2_reconnect_server [cifs]
RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0
Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 ad
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
7b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8
RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83
RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6b
RDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800
RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000
R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000
FS: 0000000000000000(0000) GS:ffff888157c00000(0000)
knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? die_addr+0x36/0x90
 ? exc_general_protection+0x1c1/0x3f0
 ? asm_exc_general_protection+0x26/0x30
 ? __list_del_entry_valid_or_report+0x33/0xf0
 __cifs_put_smb_ses+0x1ae/0x500 [cifs]
 smb2_reconnect_server+0x4ed/0x710 [cifs]
 process_one_work+0x205/0x6b0
 worker_thread+0x191/0x360
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xe2/0x110
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x34/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
CVE-2024-27393:In the Linux kernel, the following vulnerability has been resolved:
xen-netfront: Add missing skb_mark_for_recycle
Notice that skb_mark_for_recycle() is introduced later than fixes tag in
commit 6a5bcd84e886 (&quot;page_pool: Allow drivers to hint on SKB recycling&quot;).
It is believed that fixes tag were missing a call to page_pool_release_page()
between v5.9 to v5.14, after which is should have used skb_mark_for_recycle().
Since v6.6 the call page_pool_release_page() were removed (in
commit 535b9c61bdef (&quot;net: page_pool: hide page_pool_release_page()&quot;)
and remaining callers converted (in commit 6bfef2ec0172 (&quot;Merge branch
'net-page_pool-remove-page_pool_release_page'&quot;)).
This leak became visible in v6.8 via commit dba1b8a7ab68 (&quot;mm/page_pool: catch
page_pool memory leaks&quot;).
CVE-2024-35967:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: SCO: Fix not validating setsockopt user input
syzbot reported sco_sock_setsockopt() is copying data without
checking user input length.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90
net/bluetooth/sco.c:893
Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578
CVE-2023-52807:In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix out-of-bounds access may occur when coalesce info is read via debugfs
The hns3 driver define an array of string to show the coalesce
info, but if the kernel adds a new mode or a new state,
out-of-bounds access may occur when coalesce info is read via
debugfs, this patch fix the problem.
CVE-2024-35951:In the Linux kernel, the following vulnerability has been resolved:
drm/panfrost: Fix the error path in panfrost_mmu_map_fault_addr()
Subject: [PATCH] drm/panfrost: Fix the error path in
 panfrost_mmu_map_fault_addr()
If some the pages or sgt allocation failed, we shouldn't release the
pages ref we got earlier, otherwise we will end up with unbalanced
get/put_pages() calls. We should instead leave everything in place
and let the BO release function deal with extra cleanup when the object
is destroyed, or let the fault handler try again next time it's called.
CVE-2024-36916:In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: avoid out of bounds shift
UBSAN catches undefined behavior in blk-iocost, where sometimes
iocg-&gt;delay is shifted right by a number that is too large,
resulting in undefined behavior on some architectures.
[  186.556576] ------------[ cut here ]------------
UBSAN: shift-out-of-bounds in block/blk-iocost.c:1366:23
shift exponent 64 is too large for 64-bit type 'u64' (aka 'unsigned long long')
CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1
Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020
Call Trace:
 &lt;IRQ&gt;
 dump_stack_lvl+0x8f/0xe0
 __ubsan_handle_shift_out_of_bounds+0x22c/0x280
 iocg_kick_delay+0x30b/0x310
 ioc_timer_fn+0x2fb/0x1f80
 __run_timer_base+0x1b6/0x250
...
Avoid that undefined behavior by simply taking the
&quot;delay = 0&quot; branch if the shift is too large.
I am not sure what the symptoms of an undefined value
delay will be, but I suspect it could be more than a
little annoying to debug.
CVE-2023-52745:In the Linux kernel, the following vulnerability has been resolved:
IB/IPoIB: Fix legacy IPoIB due to wrong number of queues
The cited commit creates child PKEY interfaces over netlink will
multiple tx and rx queues, but some devices doesn't support more than 1
tx and 1 rx queues. This causes to a crash when traffic is sent over the
PKEY interface due to the parent having a single queue but the child
having multiple queues.
This patch fixes the number of queues to 1 for legacy IPoIB at the
earliest possible point in time.
BUG: kernel NULL pointer dereference, address: 000000000000036b
PGD 0 P4D 0
Oops: 0000 [#1] SMP
CPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
RIP: 0010:kmem_cache_alloc+0xcb/0x450
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
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
RSP: 0018:ffff88822acbbab8 EFLAGS: 00010202
RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8dae
RDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00
RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40
R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000
R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000
FS:  00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
 skb_clone+0x55/0xd0
 ip6_finish_output2+0x3fe/0x690
 ip6_finish_output+0xfa/0x310
 ip6_send_skb+0x1e/0x60
 udp_v6_send_skb+0x1e5/0x420
 udpv6_sendmsg+0xb3c/0xe60
 ? ip_mc_finish_output+0x180/0x180
 ? __switch_to_asm+0x3a/0x60
 ? __switch_to_asm+0x34/0x60
 sock_sendmsg+0x33/0x40
 __sys_sendto+0x103/0x160
 ? _copy_to_user+0x21/0x30
 ? kvm_clock_get_cycles+0xd/0x10
 ? ktime_get_ts64+0x49/0xe0
 __x64_sys_sendto+0x25/0x30
 do_syscall_64+0x3d/0x90
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
RIP: 0033:0x7f9374f1ed14
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
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
RSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002c
RAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14
RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030
RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001c
R10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000
R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc
 &lt;/TASK&gt;
CVE-2024-36902:In the Linux kernel, the following vulnerability has been resolved:
ipv6: fib6_rules: avoid possible NULL dereference in fib6_rule_action()
syzbot is able to trigger the following crash [1],
caused by unsafe ip6_dst_idev() use.
Indeed ip6_dst_idev() can return NULL, and must always be checked.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 RIP: 0010:__fib6_rule_action net/ipv6/fib6_rules.c:237 [inline]
 RIP: 0010:fib6_rule_action+0x241/0x7b0 net/ipv6/fib6_rules.c:267
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
RSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700
RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760
RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bd
R10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000
R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00
FS:  00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  fib_rules_lookup+0x62c/0xdb0 net/core/fib_rules.c:317
  fib6_rule_lookup+0x1fd/0x790 net/ipv6/fib6_rules.c:108
  ip6_route_output_flags_noref net/ipv6/route.c:2637 [inline]
  ip6_route_output_flags+0x38e/0x610 net/ipv6/route.c:2649
  ip6_route_output include/net/ip6_route.h:93 [inline]
  ip6_dst_lookup_tail+0x189/0x11a0 net/ipv6/ip6_output.c:1120
  ip6_dst_lookup_flow+0xb9/0x180 net/ipv6/ip6_output.c:1250
  sctp_v6_get_dst+0x792/0x1e20 net/sctp/ipv6.c:326
  sctp_transport_route+0x12c/0x2e0 net/sctp/transport.c:455
  sctp_assoc_add_peer+0x614/0x15c0 net/sctp/associola.c:662
  sctp_connect_new_asoc+0x31d/0x6c0 net/sctp/socket.c:1099
  __sctp_connect+0x66d/0xe30 net/sctp/socket.c:1197
  sctp_connect net/sctp/socket.c:4819 [inline]
  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
  __sys_connect_file net/socket.c:2048 [inline]
  __sys_connect+0x2df/0x310 net/socket.c:2065
  __do_sys_connect net/socket.c:2075 [inline]
  __se_sys_connect net/socket.c:2072 [inline]
  __x64_sys_connect+0x7a/0x90 net/socket.c:2072
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2024-35809:In the Linux kernel, the following vulnerability has been resolved:
PCI/PM: Drain runtime-idle callbacks before driver removal
A race condition between the .runtime_idle() callback and the .remove()
callback in the rtsx_pcr PCI driver leads to a kernel crash due to an
unhandled page fault [1].
The problem is that rtsx_pci_runtime_idle() is not expected to be running
after pm_runtime_get_sync() has been called, but the latter doesn't really
guarantee that.  It only guarantees that the suspend and resume callbacks
will not be running when it returns.
However, if a .runtime_idle() callback is already running when
pm_runtime_get_sync() is called, the latter will notice that the runtime PM
status of the device is RPM_ACTIVE and it will return right away without
waiting for the former to complete.  In fact, it cannot wait for
.runtime_idle() to complete because it may be called from that callback (it
arguably does not make much sense to do that, but it is not strictly
prohibited).
Thus in general, whoever is providing a .runtime_idle() callback needs
to protect it from running in parallel with whatever code runs after
pm_runtime_get_sync().  [Note that .runtime_idle() will not start after
pm_runtime_get_sync() has returned, but it may continue running then if it
has started earlier.]
One way to address that race condition is to call pm_runtime_barrier()
after pm_runtime_get_sync() (not before it, because a nonzero value of the
runtime PM usage counter is necessary to prevent runtime PM callbacks from
being invoked) to wait for the .runtime_idle() callback to complete should
it be running at that point.  A suitable place for doing that is in
pci_device_remove() which calls pm_runtime_get_sync() before removing the
driver, so it may as well call pm_runtime_barrier() subsequently, which
will prevent the race in question from occurring, not just in the rtsx_pcr
driver, but in any PCI drivers providing .runtime_idle() callbacks.
CVE-2023-52775:In the Linux kernel, the following vulnerability has been resolved:
net/smc: avoid data corruption caused by decline
We found a data corruption issue during testing of SMC-R on Redis
applications.
The benchmark has a low probability of reporting a strange error as
shown below.
&quot;Error: Protocol error, got &quot;\xe2&quot; as reply type byte&quot;
Finally, we found that the retrieved error data was as follows:
0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C
0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x00
0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2
It is quite obvious that this is a SMC DECLINE message, which means that
the applications received SMC protocol message.
We found that this was caused by the following situations:
client                  server
        ¦  clc proposal
        -------------&gt;
        ¦  clc accept
        &lt;-------------
        ¦  clc confirm
        -------------&gt;
wait llc confirm
			send llc confirm
        ¦failed llc confirm
        ¦   x------
(after 2s)timeout
                        wait llc confirm rsp
wait decline
(after 1s) timeout
                        (after 2s) timeout
        ¦   decline
        --------------&gt;
        ¦   decline
        &lt;--------------
As a result, a decline message was sent in the implementation, and this
message was read from TCP by the already-fallback connection.
This patch double the client timeout as 2x of the server value,
With this simple change, the Decline messages should never cross or
collide (during Confirm link timeout).
This issue requires an immediate solution, since the protocol updates
involve a more long-term solution.
CVE-2024-36908:In the Linux kernel, the following vulnerability has been resolved:
blk-iocost: do not WARN if iocg was already offlined
In iocg_pay_debt(), warn is triggered if 'active_list' is empty, which
is intended to confirm iocg is active when it has debt. However, warn
can be triggered during a blkcg or disk removal, if iocg_waitq_timer_fn()
is run at that time:
  WARNING: CPU: 0 PID: 2344971 at block/blk-iocost.c:1402 iocg_pay_debt+0x14c/0x190
  Call trace:
  iocg_pay_debt+0x14c/0x190
  iocg_kick_waitq+0x438/0x4c0
  iocg_waitq_timer_fn+0xd8/0x130
  __run_hrtimer+0x144/0x45c
  __hrtimer_run_queues+0x16c/0x244
  hrtimer_interrupt+0x2cc/0x7b0
The warn in this situation is meaningless. Since this iocg is being
removed, the state of the 'active_list' is irrelevant, and 'waitq_timer'
is canceled after removing 'active_list' in ioc_pd_free(), which ensures
iocg is freed after iocg_waitq_timer_fn() returns.
Therefore, add the check if iocg was already offlined to avoid warn
when removing a blkcg or disk.
CVE-2024-36901:In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent NULL dereference in ip6_output()
According to syzbot, there is a chance that ip6_dst_idev()
returns NULL in ip6_output(). Most places in IPv6 stack
deal with a NULL idev just fine, but not here.
syzbot reported:
general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]
CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237
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
RSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000
RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48
RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fad
R10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0
R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000
FS:  00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  NF_HOOK include/linux/netfilter.h:314 [inline]
  ip6_xmit+0xefe/0x17f0 net/ipv6/ip6_output.c:358
  sctp_v6_xmit+0x9f2/0x13f0 net/sctp/ipv6.c:248
  sctp_packet_transmit+0x26ad/0x2ca0 net/sctp/output.c:653
  sctp_packet_singleton+0x22c/0x320 net/sctp/outqueue.c:783
  sctp_outq_flush_ctrl net/sctp/outqueue.c:914 [inline]
  sctp_outq_flush+0x6d5/0x3e20 net/sctp/outqueue.c:1212
  sctp_side_effects net/sctp/sm_sideeffect.c:1198 [inline]
  sctp_do_sm+0x59cc/0x60c0 net/sctp/sm_sideeffect.c:1169
  sctp_primitive_ASSOCIATE+0x95/0xc0 net/sctp/primitive.c:73
  __sctp_connect+0x9cd/0xe30 net/sctp/socket.c:1234
  sctp_connect net/sctp/socket.c:4819 [inline]
  sctp_inet_connect+0x149/0x1f0 net/sctp/socket.c:4834
  __sys_connect_file net/socket.c:2048 [inline]
  __sys_connect+0x2df/0x310 net/socket.c:2065
  __do_sys_connect net/socket.c:2075 [inline]
  __se_sys_connect net/socket.c:2072 [inline]
  __x64_sys_connect+0x7a/0x90 net/socket.c:2072
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2024-36960:In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix invalid reads in fence signaled events
Correctly set the length of the drm_event to the size of the structure
that's actually used.
The length of the drm_event was set to the parent structure instead of
to the drm_vmw_event_fence which is supposed to be read. drm_read
uses the length parameter to copy the event to the user space thus
resuling in oob reads.
CVE-2024-36929:In the Linux kernel, the following vulnerability has been resolved:
net: core: reject skb_copy(_expand) for fraglist GSO skbs
SKB_GSO_FRAGLIST skbs must not be linearized, otherwise they become
invalid. Return NULL if such an skb is passed to skb_copy or
skb_copy_expand, in order to prevent a crash on a potential later
call to skb_gso_segment.
CVE-2024-36952:In the Linux kernel, the following vulnerability has been resolved:
scsi: lpfc: Move NPIV's transport unregistration to after resource clean up
There are cases after NPIV deletion where the fabric switch still believes
the NPIV is logged into the fabric.  This occurs when a vport is
unregistered before the Remove All DA_ID CT and LOGO ELS are sent to the
fabric.
Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs including
the fabric D_ID, removes the last ndlp reference and frees the ndlp rport
object.  This sometimes causes the race condition where the final DA_ID and
LOGO are skipped from being sent to the fabric switch.
Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_ID
and LOGO are sent.
CVE-2024-36933:In the Linux kernel, the following vulnerability has been resolved:
nsh: Restore skb-&gt;{protocol,data,mac_header} for outer header in nsh_gso_segment().
syzbot triggered various splats (see [0] and links) by a crafted GSO
packet of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:
  ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDP
NSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS.  As the inner
protocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), calls
skb_mac_gso_segment() to invoke inner protocol GSO handlers.
nsh_gso_segment() does the following for the original skb before
calling skb_mac_gso_segment()
  1. reset skb-&gt;network_header
  2. save the original skb-&gt;{mac_heaeder,mac_len} in a local variable
  3. pull the NSH header
  4. resets skb-&gt;mac_header
  5. set up skb-&gt;mac_len and skb-&gt;protocol for the inner protocol.
and does the following for the segmented skb
  6. set ntohs(ETH_P_NSH) to skb-&gt;protocol
  7. push the NSH header
  8. restore skb-&gt;mac_header
  9. set skb-&gt;mac_header + mac_len to skb-&gt;network_header
 10. restore skb-&gt;mac_len
There are two problems in 6-7 and 8-9.
  (a)
  After 6 &amp; 7, skb-&gt;data points to the NSH header, so the outer header
  (ETH_P_8021AD in this case) is stripped when skb is sent out of netdev.
  Also, if NSH is encapsulated by NSH + Ethernet (so NSH-Ethernet-NSH),
  skb_pull() in the first nsh_gso_segment() will make skb-&gt;data point
  to the middle of the outer NSH or Ethernet header because the Ethernet
  header is not pulled by the second nsh_gso_segment().
  (b)
  While restoring skb-&gt;{mac_header,network_header} in 8 &amp; 9,
  nsh_gso_segment() does not assume that the data in the linear
  buffer is shifted.
  However, udp6_ufo_fragment() could shift the data and change
  skb-&gt;mac_header accordingly as demonstrated by syzbot.
  If this happens, even the restored skb-&gt;mac_header points to
  the middle of the outer header.
It seems nsh_gso_segment() has never worked with outer headers so far.
At the end of nsh_gso_segment(), the outer header must be restored for
the segmented skb, instead of the NSH header.
To do that, let's calculate the outer header position relatively from
the inner header and set skb-&gt;{data,mac_header,protocol} properly.
[0]:
BUG: KMSAN: uninit-value in ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]
BUG: KMSAN: uninit-value in ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
BUG: KMSAN: uninit-value in ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668
 ipvlan_process_outbound drivers/net/ipvlan/ipvlan_core.c:524 [inline]
 ipvlan_xmit_mode_l3 drivers/net/ipvlan/ipvlan_core.c:602 [inline]
 ipvlan_queue_xmit+0xf44/0x16b0 drivers/net/ipvlan/ipvlan_core.c:668
 ipvlan_start_xmit+0x5c/0x1a0 drivers/net/ipvlan/ipvlan_main.c:222
 __netdev_start_xmit include/linux/netdevice.h:4989 [inline]
 netdev_start_xmit include/linux/netdevice.h:5003 [inline]
 xmit_one net/core/dev.c:3547 [inline]
 dev_hard_start_xmit+0x244/0xa10 net/core/dev.c:3563
 __dev_queue_xmit+0x33ed/0x51c0 net/core/dev.c:4351
 dev_queue_xmit include/linux/netdevice.h:3171 [inline]
 packet_xmit+0x9c/0x6b0 net/packet/af_packet.c:276
 packet_snd net/packet/af_packet.c:3081 [inline]
 packet_sendmsg+0x8aef/0x9f10 net/packet/af_packet.c:3113
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 __sys_sendto+0x735/0xa10 net/socket.c:2191
 __do_sys_sendto net/socket.c:2203 [inline]
 __se_sys_sendto net/socket.c:2199 [inline]
 __x64_sys_sendto+0x125/0x1c0 net/socket.c:2199
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
Uninit was created at:
 slab_post_alloc_hook mm/slub.c:3819 [inline]
 slab_alloc_node mm/slub.c:3860 [inline]
 __do_kmalloc_node mm/slub.c:3980 [inline]
 __kmalloc_node_track_caller+0x705/0x1000 mm/slub.c:4001
 kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582
 __
---truncated---
CVE-2024-36883:In the Linux kernel, the following vulnerability has been resolved:
net: fix out-of-bounds access in ops_init
net_alloc_generic is called by net_alloc, which is called without any
locking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. It
is read twice, first to allocate an array, then to set s.len, which is
later used to limit the bounds of the array access.
It is possible that the array is allocated and another thread is
registering a new pernet ops, increments max_gen_ptrs, which is then used
to set s.len with a larger than allocated length for the variable array.
Fix it by reading max_gen_ptrs only once in net_alloc_generic. If
max_gen_ptrs is later incremented, it will be caught in net_assign_generic.
CVE-2023-52680:In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add missing error checks to *_ctl_get()
The *_ctl_get() functions which call scarlett2_update_*() were not
checking the return value. Fix to check the return value and pass to
the caller.
CVE-2021-47247:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix use-after-free of encap entry in neigh update handler
Function mlx5e_rep_neigh_update() wasn't updated to accommodate rtnl lock
removal from TC filter update path and properly handle concurrent encap
entry insertion/deletion which can lead to following use-after-free:
 [23827.464923] ==================================================================
 [23827.469446] BUG: KASAN: use-after-free in mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.470971] Read of size 4 at addr ffff8881d132228c by task kworker/u20:6/21635
 [23827.472251]
 [23827.472615] CPU: 9 PID: 21635 Comm: kworker/u20:6 Not tainted 5.13.0-rc3+ #5
 [23827.473788] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
 [23827.475639] Workqueue: mlx5e mlx5e_rep_neigh_update [mlx5_core]
 [23827.476731] Call Trace:
 [23827.477260]  dump_stack+0xbb/0x107
 [23827.477906]  print_address_description.constprop.0+0x18/0x140
 [23827.478896]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.479879]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.480905]  kasan_report.cold+0x7c/0xd8
 [23827.481701]  ? mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.482744]  kasan_check_range+0x145/0x1a0
 [23827.493112]  mlx5e_encap_take+0x72/0x140 [mlx5_core]
 [23827.494054]  ? mlx5e_tc_tun_encap_info_equal_generic+0x140/0x140 [mlx5_core]
 [23827.495296]  mlx5e_rep_neigh_update+0x41e/0x5e0 [mlx5_core]
 [23827.496338]  ? mlx5e_rep_neigh_entry_release+0xb80/0xb80 [mlx5_core]
 [23827.497486]  ? read_word_at_a_time+0xe/0x20
 [23827.498250]  ? strscpy+0xa0/0x2a0
 [23827.498889]  process_one_work+0x8ac/0x14e0
 [23827.499638]  ? lockdep_hardirqs_on_prepare+0x400/0x400
 [23827.500537]  ? pwq_dec_nr_in_flight+0x2c0/0x2c0
 [23827.501359]  ? rwlock_bug.part.0+0x90/0x90
 [23827.502116]  worker_thread+0x53b/0x1220
 [23827.502831]  ? process_one_work+0x14e0/0x14e0
 [23827.503627]  kthread+0x328/0x3f0
 [23827.504254]  ? _raw_spin_unlock_irq+0x24/0x40
 [23827.505065]  ? __kthread_bind_mask+0x90/0x90
 [23827.505912]  ret_from_fork+0x1f/0x30
 [23827.506621]
 [23827.506987] Allocated by task 28248:
 [23827.507694]  kasan_save_stack+0x1b/0x40
 [23827.508476]  __kasan_kmalloc+0x7c/0x90
 [23827.509197]  mlx5e_attach_encap+0xde1/0x1d40 [mlx5_core]
 [23827.510194]  mlx5e_tc_add_fdb_flow+0x397/0xc40 [mlx5_core]
 [23827.511218]  __mlx5e_add_fdb_flow+0x519/0xb30 [mlx5_core]
 [23827.512234]  mlx5e_configure_flower+0x191c/0x4870 [mlx5_core]
 [23827.513298]  tc_setup_cb_add+0x1d5/0x420
 [23827.514023]  fl_hw_replace_filter+0x382/0x6a0 [cls_flower]
 [23827.514975]  fl_change+0x2ceb/0x4a51 [cls_flower]
 [23827.515821]  tc_new_tfilter+0x89a/0x2070
 [23827.516548]  rtnetlink_rcv_msg+0x644/0x8c0
 [23827.517300]  netlink_rcv_skb+0x11d/0x340
 [23827.518021]  netlink_unicast+0x42b/0x700
 [23827.518742]  netlink_sendmsg+0x743/0xc20
 [23827.519467]  sock_sendmsg+0xb2/0xe0
 [23827.520131]  ____sys_sendmsg+0x590/0x770
 [23827.520851]  ___sys_sendmsg+0xd8/0x160
 [23827.521552]  __sys_sendmsg+0xb7/0x140
 [23827.522238]  do_syscall_64+0x3a/0x70
 [23827.522907]  entry_SYSCALL_64_after_hwframe+0x44/0xae
 [23827.523797]
 [23827.524163] Freed by task 25948:
 [23827.524780]  kasan_save_stack+0x1b/0x40
 [23827.525488]  kasan_set_track+0x1c/0x30
 [23827.526187]  kasan_set_free_info+0x20/0x30
 [23827.526968]  __kasan_slab_free+0xed/0x130
 [23827.527709]  slab_free_freelist_hook+0xcf/0x1d0
 [23827.528528]  kmem_cache_free_bulk+0x33a/0x6e0
 [23827.529317]  kfree_rcu_work+0x55f/0xb70
 [23827.530024]  process_one_work+0x8ac/0x14e0
 [23827.530770]  worker_thread+0x53b/0x1220
 [23827.531480]  kthread+0x328/0x3f0
 [23827.532114]  ret_from_fork+0x1f/0x30
 [23827.532785]
 [23827.533147] Last potentially related work creation:
 [23827.534007]  kasan_save_stack+0x1b/0x40
 [23827.534710]  kasan_record_aux_stack+0xab/0xc0
 [23827.535492]  kvfree_call_rcu+0x31/0x7b0
 [23827.536206]  mlx5e_tc_del
---truncated---
CVE-2024-36899:In the Linux kernel, the following vulnerability has been resolved:
gpiolib: cdev: Fix use after free in lineinfo_changed_notify
The use-after-free issue occurs as follows: when the GPIO chip device file
is being closed by invoking gpio_chrdev_release(), watched_lines is freed
by bitmap_free(), but the unregistration of lineinfo_changed_nb notifier
chain failed due to waiting write rwsem. Additionally, one of the GPIO
chip's lines is also in the release process and holds the notifier chain's
read rwsem. Consequently, a race condition leads to the use-after-free of
watched_lines.
Here is the typical stack when issue happened:
[free]
gpio_chrdev_release()
  --&gt; bitmap_free(cdev-&gt;watched_lines)                  &lt;-- freed
  --&gt; blocking_notifier_chain_unregister()
    --&gt; down_write(&amp;nh-&gt;rwsem)                          &lt;-- waiting rwsem
          --&gt; __down_write_common()
            --&gt; rwsem_down_write_slowpath()
                  --&gt; schedule_preempt_disabled()
                    --&gt; schedule()
[use]
st54spi_gpio_dev_release()
  --&gt; gpio_free()
    --&gt; gpiod_free()
      --&gt; gpiod_free_commit()
        --&gt; gpiod_line_state_notify()
          --&gt; blocking_notifier_call_chain()
            --&gt; down_read(&amp;nh-&gt;rwsem);                  &lt;-- held rwsem
            --&gt; notifier_call_chain()
              --&gt; lineinfo_changed_notify()
                --&gt; test_bit(xxxx, cdev-&gt;watched_lines) &lt;-- use after free
The side effect of the use-after-free issue is that a GPIO line event is
being generated for userspace where it shouldn't. However, since the chrdev
is being closed, userspace won't have the chance to read that event anyway.
To fix the issue, call the bitmap_free() function after the unregistration
of lineinfo_changed_nb notifier chain.
CVE-2023-52672:In the Linux kernel, the following vulnerability has been resolved:
pipe: wakeup wr_wait after setting max_usage
Commit c73be61cede5 (&quot;pipe: Add general notification queue support&quot;) a
regression was introduced that would lock up resized pipes under certain
conditions. See the reproducer in [1].
The commit resizing the pipe ring size was moved to a different
function, doing that moved the wakeup for pipe-&gt;wr_wait before actually
raising pipe-&gt;max_usage. If a pipe was full before the resize occured it
would result in the wakeup never actually triggering pipe_write.
Set @max_usage and @nr_accounted before waking writers if this isn't a
watch queue.
[Christian Brauner &lt;brauner@kernel.org&gt;: rewrite to account for watch queues]
CVE-2023-52732:In the Linux kernel, the following vulnerability has been resolved:
ceph: blocklist the kclient when receiving corrupted snap trace
When received corrupted snap trace we don't know what exactly has
happened in MDS side. And we shouldn't continue IOs and metadatas
access to MDS, which may corrupt or get incorrect contents.
This patch will just block all the further IO/MDS requests
immediately and then evict the kclient itself.
The reason why we still need to evict the kclient just after
blocking all the further IOs is that the MDS could revoke the caps
faster.
CVE-2023-52882:In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate change
While PLL CPUX clock rate change when CPU is running from it works in
vast majority of cases, now and then it causes instability. This leads
to system crashes and other undefined behaviour. After a lot of testing
(30+ hours) while also doing a lot of frequency switches, we can't
observe any instability issues anymore when doing reparenting to stable
clock like 24 MHz oscillator.
CVE-2024-35924:In the Linux kernel, the following vulnerability has been resolved:
usb: typec: ucsi: Limit read size on v1.2
Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region was
increased from 16 to 256. In order to avoid overflowing reads for older
systems, add a mechanism to use the read UCSI version to truncate read
sizes on UCSI v1.2.
CVE-2022-48652:In the Linux kernel, the following vulnerability has been resolved:
ice: Fix crash by keep old cfg when update TCs more than queues
There are problems if allocated queues less than Traffic Classes.
Commit a632b2a4c920 (&quot;ice: ethtool: Prohibit improper channel config
for DCB&quot;) already disallow setting less queues than TCs.
Another case is if we first set less queues, and later update more TCs
config due to LLDP, ice_vsi_cfg_tc() will failed but left dirty
num_txq/rxq and tc_cfg in vsi, that will cause invalid pointer access.
[   95.968089] ice 0000:3b:00.1: More TCs defined than queues/rings allocated.
[   95.968092] ice 0000:3b:00.1: Trying to use more Rx queues (8), than were allocated (1)!
[   95.968093] ice 0000:3b:00.1: Failed to config TC for VSI index: 0
[   95.969621] general protection fault: 0000 [#1] SMP NOPTI
[   95.969705] CPU: 1 PID: 58405 Comm: lldpad Kdump: loaded Tainted: G     U  W  O     --------- -t - 4.18.0 #1
[   95.969867] Hardware name: O.E.M/BC11SPSCB10, BIOS 8.23 12/30/2021
[   95.969992] RIP: 0010:devm_kmalloc+0xa/0x60
[   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
[   95.970344] RSP: 0018:ffffc9003f553888 EFLAGS: 00010206
[   95.970425] RAX: dead000000000200 RBX: ffffea003c425b00 RCX: 00000000006080c0
[   95.970536] RDX: 00000000006080c0 RSI: 0000000000000200 RDI: dead000000000200
[   95.970648] RBP: dead000000000200 R08: 00000000000463c0 R09: ffff888ffa900000
[   95.970760] R10: 0000000000000000 R11: 0000000000000002 R12: ffff888ff6b40100
[   95.970870] R13: ffff888ff6a55018 R14: 0000000000000000 R15: ffff888ff6a55460
[   95.970981] FS:  00007f51b7d24700(0000) GS:ffff88903ee80000(0000) knlGS:0000000000000000
[   95.971108] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   95.971197] CR2: 00007fac5410d710 CR3: 0000000f2c1de002 CR4: 00000000007606e0
[   95.971309] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   95.971419] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   95.971530] PKRU: 55555554
[   95.971573] Call Trace:
[   95.971622]  ice_setup_rx_ring+0x39/0x110 [ice]
[   95.971695]  ice_vsi_setup_rx_rings+0x54/0x90 [ice]
[   95.971774]  ice_vsi_open+0x25/0x120 [ice]
[   95.971843]  ice_open_internal+0xb8/0x1f0 [ice]
[   95.971919]  ice_ena_vsi+0x4f/0xd0 [ice]
[   95.971987]  ice_dcb_ena_dis_vsi.constprop.5+0x29/0x90 [ice]
[   95.972082]  ice_pf_dcb_cfg+0x29a/0x380 [ice]
[   95.972154]  ice_dcbnl_setets+0x174/0x1b0 [ice]
[   95.972220]  dcbnl_ieee_set+0x89/0x230
[   95.972279]  ? dcbnl_ieee_del+0x150/0x150
[   95.972341]  dcb_doit+0x124/0x1b0
[   95.972392]  rtnetlink_rcv_msg+0x243/0x2f0
[   95.972457]  ? dcb_doit+0x14d/0x1b0
[   95.972510]  ? __kmalloc_node_track_caller+0x1d3/0x280
[   95.972591]  ? rtnl_calcit.isra.31+0x100/0x100
[   95.972661]  netlink_rcv_skb+0xcf/0xf0
[   95.972720]  netlink_unicast+0x16d/0x220
[   95.972781]  netlink_sendmsg+0x2ba/0x3a0
[   95.975891]  sock_sendmsg+0x4c/0x50
[   95.979032]  ___sys_sendmsg+0x2e4/0x300
[   95.982147]  ? kmem_cache_alloc+0x13e/0x190
[   95.985242]  ? __wake_up_common_lock+0x79/0x90
[   95.988338]  ? __check_object_size+0xac/0x1b0
[   95.991440]  ? _copy_to_user+0x22/0x30
[   95.994539]  ? move_addr_to_user+0xbb/0xd0
[   95.997619]  ? __sys_sendmsg+0x53/0x80
[   96.000664]  __sys_sendmsg+0x53/0x80
[   96.003747]  do_syscall_64+0x5b/0x1d0
[   96.006862]  entry_SYSCALL_64_after_hwframe+0x65/0xca
Only update num_txq/rxq when passed check, and restore tc_cfg if setup
queue map failed.
CVE-2023-52693:In the Linux kernel, the following vulnerability has been resolved:
ACPI: video: check for error while searching for backlight device parent
If acpi_get_parent() called in acpi_video_dev_register_backlight()
fails, for example, because acpi_ut_acquire_mutex() fails inside
acpi_get_parent), this can lead to incorrect (uninitialized)
acpi_parent handle being passed to acpi_get_pci_dev() for detecting
the parent pci device.
Check acpi_get_parent() result and set parent device only in case of success.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-35915:In the Linux kernel, the following vulnerability has been resolved:
nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packet
syzbot reported the following uninit-value access issue [1][2]:
nci_rx_work() parses and processes received packet. When the payload
length is zero, each message type handler reads uninitialized payload
and KMSAN detects this issue. The receipt of a packet with a zero-size
payload is considered unexpected, and therefore, such packets should be
silently discarded.
This patch resolved this issue by checking payload size before calling
each message type handler codes.
CVE-2024-36949:In the Linux kernel, the following vulnerability has been resolved:
amd/amdkfd: sync all devices to wait all processes being evicted
If there are more than one device doing reset in parallel, the first
device will call kfd_suspend_all_processes() to evict all processes
on all devices, this call takes time to finish. other device will
start reset and recover without waiting. if the process has not been
evicted before doing recover, it will be restored, then caused page
fault.
CVE-2023-52708:In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_spi: fix error handling in mmc_spi_probe()
If mmc_add_host() fails, it doesn't need to call mmc_remove_host(),
or it will cause null-ptr-deref, because of deleting a not added
device in mmc_remove_host().
To fix this, goto label 'fail_glue_init', if mmc_add_host() fails,
and change the label 'fail_add_host' to 'fail_gpiod_request'.
CVE-2023-52762:In the Linux kernel, the following vulnerability has been resolved:
virtio-blk: fix implicit overflow on virtio_max_dma_size
The following codes have an implicit conversion from size_t to u32:
(u32)max_size = (size_t)virtio_max_dma_size(vdev);
This may lead overflow, Ex (size_t)4G -&gt; (u32)0. Once
virtio_max_dma_size() has a larger size than U32_MAX, use U32_MAX
instead.
CVE-2024-36905:In the Linux kernel, the following vulnerability has been resolved:
tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV sockets
TCP_SYN_RECV state is really special, it is only used by
cross-syn connections, mostly used by fuzzers.
In the following crash [1], syzbot managed to trigger a divide
by zero in tcp_rcv_space_adjust()
A socket makes the following state transitions,
without ever calling tcp_init_transfer(),
meaning tcp_init_buffer_space() is also not called.
         TCP_CLOSE
connect()
         TCP_SYN_SENT
         TCP_SYN_RECV
shutdown() -&gt; tcp_shutdown(sk, SEND_SHUTDOWN)
         TCP_FIN_WAIT1
To fix this issue, change tcp_shutdown() to not
perform a TCP_SYN_RECV -&gt; TCP_FIN_WAIT1 transition,
which makes no sense anyway.
When tcp_rcv_state_process() later changes socket state
from TCP_SYN_RECV to TCP_ESTABLISH, then look at
sk-&gt;sk_shutdown to finally enter TCP_FIN_WAIT1 state,
and send a FIN packet from a sane socket state.
This means tcp_send_fin() can now be called from BH
context, and must use GFP_ATOMIC allocations.
[1]
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 RIP: 0010:tcp_rcv_space_adjust+0x2df/0x890 net/ipv4/tcp_input.c:767
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
RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246
RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000
RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7
R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30
R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2da
FS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
  tcp_recvmsg_locked+0x106d/0x25a0 net/ipv4/tcp.c:2513
  tcp_recvmsg+0x25d/0x920 net/ipv4/tcp.c:2578
  inet6_recvmsg+0x16a/0x730 net/ipv6/af_inet6.c:680
  sock_recvmsg_nosec net/socket.c:1046 [inline]
  sock_recvmsg+0x109/0x280 net/socket.c:1068
  ____sys_recvmsg+0x1db/0x470 net/socket.c:2803
  ___sys_recvmsg net/socket.c:2845 [inline]
  do_recvmmsg+0x474/0xae0 net/socket.c:2939
  __sys_recvmmsg net/socket.c:3018 [inline]
  __do_sys_recvmmsg net/socket.c:3041 [inline]
  __se_sys_recvmmsg net/socket.c:3034 [inline]
  __x64_sys_recvmmsg+0x199/0x250 net/socket.c:3034
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7faeb6363db9
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
RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012b
RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9
RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005
RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001c
R10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001
CVE-2024-36928:In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: Fix kernel panic after setting hsuid
Symptom:
When the hsuid attribute is set for the first time on an IQD Layer3
device while the corresponding network interface is already UP,
the kernel will try to execute a napi function pointer that is NULL.
Example:
---------------------------------------------------------------------------
[ 2057.572696] illegal operation: 0001 ilc:1 [#1] SMP
[ 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
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
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
 qdio ccwgroup pkey zcrypt
[ 2057.572739] CPU: 6 PID: 60182 Comm: stress_client Kdump: loaded Not tainted 4.18.0-541.el8.s390x #1
[ 2057.572742] Hardware name: IBM 3931 A01 704 (LPAR)
[ 2057.572744] Krnl PSW : 0704f00180000000 0000000000000002 (0x2)
[ 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
[ 2057.572751] Krnl GPRS: 0000000000000004 0000000000000000 00000000a3b008d8 0000000000000000
[ 2057.572754]            00000000a3b008d8 cb923a29c779abc5 0000000000000000 00000000814cfd80
[ 2057.572756]            000000000000012c 0000000000000000 00000000a3b008d8 00000000a3b008d8
[ 2057.572758]            00000000bab6d500 00000000814cfd80 0000000091317e46 00000000814cfc68
[ 2057.572762] Krnl Code:#0000000000000000: 0000                illegal
                         &gt;0000000000000002: 0000                illegal
                          0000000000000004: 0000                illegal
                          0000000000000006: 0000                illegal
                          0000000000000008: 0000                illegal
                          000000000000000a: 0000                illegal
                          000000000000000c: 0000                illegal
                          000000000000000e: 0000                illegal
[ 2057.572800] Call Trace:
[ 2057.572801] ([&lt;00000000ec639700&gt;] 0xec639700)
[ 2057.572803]  [&lt;00000000913183e2&gt;] net_rx_action+0x2ba/0x398
[ 2057.572809]  [&lt;0000000091515f76&gt;] __do_softirq+0x11e/0x3a0
[ 2057.572813]  [&lt;0000000090ce160c&gt;] do_softirq_own_stack+0x3c/0x58
[ 2057.572817] ([&lt;0000000090d2cbd6&gt;] do_softirq.part.1+0x56/0x60)
[ 2057.572822]  [&lt;0000000090d2cc60&gt;] __local_bh_enable_ip+0x80/0x98
[ 2057.572825]  [&lt;0000000091314706&gt;] __dev_queue_xmit+0x2be/0xd70
[ 2057.572827]  [&lt;000003ff803dd6d6&gt;] afiucv_hs_send+0x24e/0x300 [af_iucv]
[ 2057.572830]  [&lt;000003ff803dd88a&gt;] iucv_send_ctrl+0x102/0x138 [af_iucv]
[ 2057.572833]  [&lt;000003ff803de72a&gt;] iucv_sock_connect+0x37a/0x468 [af_iucv]
[ 2057.572835]  [&lt;00000000912e7e90&gt;] __sys_connect+0xa0/0xd8
[ 2057.572839]  [&lt;00000000912e9580&gt;] sys_socketcall+0x228/0x348
[ 2057.572841]  [&lt;0000000091514e1a&gt;] system_call+0x2a6/0x2c8
[ 2057.572843] Last Breaking-Event-Address:
[ 2057.572844]  [&lt;0000000091317e44&gt;] __napi_poll+0x4c/0x1d8
[ 2057.572846]
[ 2057.572847] Kernel panic - not syncing: Fatal exception in interrupt
-------------------------------------------------------------------------------------------
Analysis:
There is one napi structure per out_q: card-&gt;qdio.out_qs[i].napi
The napi.poll functions are set during qeth_open().
Since
commit 1cfef80d4c2b (&quot;s390/qeth: Don't call dev_close/dev_open (DOWN/UP)&quot;)
qeth_set_offline()/qeth_set_online() no longer call dev_close()/
dev_open(). So if qeth_free_qdio_queues() cleared
card-&gt;qdio.out_qs[i].napi.poll while the network interface was UP and the
card was offline, they are not set again.
Reproduction:
chzdev -e $devno layer2=0
ip link set dev $network_interface up
echo 0 &gt; /sys/bus/ccw
---truncated---
CVE-2024-36919:In the Linux kernel, the following vulnerability has been resolved:
scsi: bnx2fc: Remove spin_lock_bh while releasing resources after upload
The session resources are used by FW and driver when session is offloaded,
once session is uploaded these resources are not used. The lock is not
required as these fields won't be used any longer. The offload and upload
calls are sequential, hence lock is not required.
This will suppress following BUG_ON():
[  449.843143] ------------[ cut here ]------------
[  449.848302] kernel BUG at mm/vmalloc.c:2727!
[  449.853072] invalid opcode: 0000 [#1] PREEMPT SMP PTI
[  449.858712] CPU: 5 PID: 1996 Comm: kworker/u24:2 Not tainted 5.14.0-118.el9.x86_64 #1
Rebooting.
[  449.867454] Hardware name: Dell Inc. PowerEdge R730/0WCJNT, BIOS 2.3.4 11/08/2016
[  449.876966] Workqueue: fc_rport_eq fc_rport_work [libfc]
[  449.882910] RIP: 0010:vunmap+0x2e/0x30
[  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
[  449.908054] RSP: 0018:ffffb83d878b3d68 EFLAGS: 00010206
[  449.913887] RAX: 0000000080000201 RBX: ffff8f4355133550 RCX: 000000000d400005
[  449.921843] RDX: 0000000000000001 RSI: 0000000000001000 RDI: ffffb83da53f5000
[  449.929808] RBP: ffff8f4ac6675800 R08: ffffb83d878b3d30 R09: 00000000000efbdf
[  449.937774] R10: 0000000000000003 R11: ffff8f434573e000 R12: 0000000000001000
[  449.945736] R13: 0000000000001000 R14: ffffb83da53f5000 R15: ffff8f43d4ea3ae0
[  449.953701] FS:  0000000000000000(0000) GS:ffff8f529fc80000(0000) knlGS:0000000000000000
[  449.962732] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  449.969138] CR2: 00007f8cf993e150 CR3: 0000000efbe10003 CR4: 00000000003706e0
[  449.977102] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  449.985065] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  449.993028] Call Trace:
[  449.995756]  __iommu_dma_free+0x96/0x100
[  450.000139]  bnx2fc_free_session_resc+0x67/0x240 [bnx2fc]
[  450.006171]  bnx2fc_upload_session+0xce/0x100 [bnx2fc]
[  450.011910]  bnx2fc_rport_event_handler+0x9f/0x240 [bnx2fc]
[  450.018136]  fc_rport_work+0x103/0x5b0 [libfc]
[  450.023103]  process_one_work+0x1e8/0x3c0
[  450.027581]  worker_thread+0x50/0x3b0
[  450.031669]  ? rescuer_thread+0x370/0x370
[  450.036143]  kthread+0x149/0x170
[  450.039744]  ? set_kthread_struct+0x40/0x40
[  450.044411]  ret_from_fork+0x22/0x30
[  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
[  450.048497]  libcxgbi libcxgb qla4xxx iscsi_boot_sysfs iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi edd ipmi_devintf ipmi_msghandler
[  450.159753] ---[ end trace 712de2c57c64abc8 ]---
CVE-2024-35830:In the Linux kernel, the following vulnerability has been resolved:
media: tc358743: register v4l2 async device only after successful setup
Ensure the device has been setup correctly before registering the v4l2
async device, thus allowing userspace to access.
CVE-2024-35828:In the Linux kernel, the following vulnerability has been resolved:
wifi: libertas: fix some memleaks in lbs_allocate_cmd_buffer()
In the for statement of lbs_allocate_cmd_buffer(), if the allocation of
cmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs to
be freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().
CVE-2024-36016:In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: fix possible out-of-bounds in gsm0_receive()
Assuming the following:
- side A configures the n_gsm in basic option mode
- side B sends the header of a basic option mode frame with data length 1
- side A switches to advanced option mode
- side B sends 2 data bytes which exceeds gsm-&gt;len
  Reason: gsm-&gt;len is not used in advanced option mode.
- side A switches to basic option mode
- side B keeps sending until gsm0_receive() writes past gsm-&gt;buf
  Reason: Neither gsm-&gt;state nor gsm-&gt;len have been reset after
  reconfiguration.
Fix this by changing gsm-&gt;count to gsm-&gt;len comparison from equal to less
than. Also add upper limit checks against the constant MAX_MRU in
gsm0_receive() and gsm1_receive() to harden against memory corruption of
gsm-&gt;len and gsm-&gt;mru.
All other checks remain as we still need to limit the data according to the
user configuration and actual payload size.
CVE-2024-36938:In the Linux kernel, the following vulnerability has been resolved:
bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueue
Fix NULL pointer data-races in sk_psock_skb_ingress_enqueue() which
syzbot reported [1].
[1]
BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueue
write to 0xffff88814b3278b8 of 8 bytes by task 10724 on cpu 1:
 sk_psock_stop_verdict net/core/skmsg.c:1257 [inline]
 sk_psock_drop+0x13e/0x1f0 net/core/skmsg.c:843
 sk_psock_put include/linux/skmsg.h:459 [inline]
 sock_map_close+0x1a7/0x260 net/core/sock_map.c:1648
 unix_release+0x4b/0x80 net/unix/af_unix.c:1048
 __sock_release net/socket.c:659 [inline]
 sock_close+0x68/0x150 net/socket.c:1421
 __fput+0x2c1/0x660 fs/file_table.c:422
 __fput_sync+0x44/0x60 fs/file_table.c:507
 __do_sys_close fs/open.c:1556 [inline]
 __se_sys_close+0x101/0x1b0 fs/open.c:1541
 __x64_sys_close+0x1f/0x30 fs/open.c:1541
 do_syscall_64+0xd3/0x1d0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
read to 0xffff88814b3278b8 of 8 bytes by task 10713 on cpu 0:
 sk_psock_data_ready include/linux/skmsg.h:464 [inline]
 sk_psock_skb_ingress_enqueue+0x32d/0x390 net/core/skmsg.c:555
 sk_psock_skb_ingress_self+0x185/0x1e0 net/core/skmsg.c:606
 sk_psock_verdict_apply net/core/skmsg.c:1008 [inline]
 sk_psock_verdict_recv+0x3e4/0x4a0 net/core/skmsg.c:1202
 unix_read_skb net/unix/af_unix.c:2546 [inline]
 unix_stream_read_skb+0x9e/0xf0 net/unix/af_unix.c:2682
 sk_psock_verdict_data_ready+0x77/0x220 net/core/skmsg.c:1223
 unix_stream_sendmsg+0x527/0x860 net/unix/af_unix.c:2339
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x140/0x180 net/socket.c:745
 ____sys_sendmsg+0x312/0x410 net/socket.c:2584
 ___sys_sendmsg net/socket.c:2638 [inline]
 __sys_sendmsg+0x1e9/0x280 net/socket.c:2667
 __do_sys_sendmsg net/socket.c:2676 [inline]
 __se_sys_sendmsg net/socket.c:2674 [inline]
 __x64_sys_sendmsg+0x46/0x50 net/socket.c:2674
 do_syscall_64+0xd3/0x1d0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
value changed: 0xffffffff83d7feb0 -&gt; 0x0000000000000000
Reported by Kernel Concurrency Sanitizer on:
CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G        W          6.8.0-syzkaller-08951-gfe46a7dd189e #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Prior to this, commit 4cd12c6065df (&quot;bpf, sockmap: Fix NULL pointer
dereference in sk_psock_verdict_data_ready()&quot;) fixed one NULL pointer
similarly due to no protection of saved_data_ready. Here is another
different caller causing the same issue because of the same reason. So
we should protect it with sk_callback_lock read lock because the writer
side in the sk_psock_drop() uses &quot;write_lock_bh(&amp;sk-&gt;sk_callback_lock);&quot;.
To avoid errors that could happen in future, I move those two pairs of
lock into the sk_psock_data_ready(), which is suggested by John Fastabend.
CVE-2023-52747:In the Linux kernel, the following vulnerability has been resolved:
IB/hfi1: Restore allocated resources on failed copyout
Fix a resource leak if an error occurs.
CVE-2024-36914:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip on writeback when it's not applicable
[WHY]
dynamic memory safety error detector (KASAN) catches and generates error
messages &quot;BUG: KASAN: slab-out-of-bounds&quot; as writeback connector does not
support certain features which are not initialized.
[HOW]
Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.
CVE-2024-35796:In the Linux kernel, the following vulnerability has been resolved:
net: ll_temac: platform_get_resource replaced by wrong function
The function platform_get_resource was replaced with
devm_platform_ioremap_resource_byname and is called using 0 as name.
This eventually ends up in platform_get_resource_byname in the call
stack, where it causes a null pointer in strcmp.
	if (type == resource_type(r) &amp;&amp; !strcmp(r-&gt;name, name))
It should have been replaced with devm_platform_ioremap_resource.
CVE-2024-35966:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: RFCOMM: Fix not validating setsockopt user input
syzbot reported rfcomm_sock_setsockopt_old() is copying data without
checking user input length.
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offset
include/linux/sockptr.h:49 [inline]
BUG: KASAN: slab-out-of-bounds in copy_from_sockptr
include/linux/sockptr.h:55 [inline]
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_old
net/bluetooth/rfcomm/sock.c:632 [inline]
BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70
net/bluetooth/rfcomm/sock.c:673
Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064
CVE-2024-35932:In the Linux kernel, the following vulnerability has been resolved:
drm/vc4: don't check if plane-&gt;state-&gt;fb == state-&gt;fb
Currently, when using non-blocking commits, we can see the following
kernel warning:
[  110.908514] ------------[ cut here ]------------
[  110.908529] refcount_t: underflow; use-after-free.
[  110.908620] WARNING: CPU: 0 PID: 1866 at lib/refcount.c:87 refcount_dec_not_one+0xb8/0xc0
[  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
[  110.909086] CPU: 0 PID: 1866 Comm: kodi.bin Tainted: G         C         6.1.66-v8+ #32
[  110.909104] Hardware name: Raspberry Pi 3 Model B Rev 1.2 (DT)
[  110.909114] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[  110.909132] pc : refcount_dec_not_one+0xb8/0xc0
[  110.909152] lr : refcount_dec_not_one+0xb4/0xc0
[  110.909170] sp : ffffffc00913b9c0
[  110.909177] x29: ffffffc00913b9c0 x28: 000000556969bbb0 x27: 000000556990df60
[  110.909205] x26: 0000000000000002 x25: 0000000000000004 x24: ffffff8004448480
[  110.909230] x23: ffffff800570b500 x22: ffffff802e03a7bc x21: ffffffecfca68c78
[  110.909257] x20: ffffff8002b42000 x19: ffffff802e03a600 x18: 0000000000000000
[  110.909283] x17: 0000000000000011 x16: ffffffffffffffff x15: 0000000000000004
[  110.909308] x14: 0000000000000fff x13: ffffffed577e47e0 x12: 0000000000000003
[  110.909333] x11: 0000000000000000 x10: 0000000000000027 x9 : c912d0d083728c00
[  110.909359] x8 : c912d0d083728c00 x7 : 65646e75203a745f x6 : 746e756f63666572
[  110.909384] x5 : ffffffed579f62ee x4 : ffffffed579eb01e x3 : 0000000000000000
[  110.909409] x2 : 0000000000000000 x1 : ffffffc00913b750 x0 : 0000000000000001
[  110.909434] Call trace:
[  110.909441]  refcount_dec_not_one+0xb8/0xc0
[  110.909461]  vc4_bo_dec_usecnt+0x4c/0x1b0 [vc4]
[  110.909903]  vc4_cleanup_fb+0x44/0x50 [vc4]
[  110.910315]  drm_atomic_helper_cleanup_planes+0x88/0xa4 [drm_kms_helper]
[  110.910669]  vc4_atomic_commit_tail+0x390/0x9dc [vc4]
[  110.911079]  commit_tail+0xb0/0x164 [drm_kms_helper]
[  110.911397]  drm_atomic_helper_commit+0x1d0/0x1f0 [drm_kms_helper]
[  110.911716]  drm_atomic_commit+0xb0/0xdc [drm]
[  110.912569]  drm_mode_atomic_ioctl+0x348/0x4b8 [drm]
[  110.913330]  drm_ioctl_kernel+0xec/0x15c [drm]
[  110.914091]  drm_ioctl+0x24c/0x3b0 [drm]
[  110.914850]  __arm64_sys_ioctl+0x9c/0xd4
[  110.914873]  invoke_syscall+0x4c/0x114
[  110.914897]  el0_svc_common+0xd0/0x118
[  110.914917]  do_el0_svc+0x38/0xd0
[  110.914936]  el0_svc+0x30/0x8c
[  110.914958]  el0t_64_sync_handler+0x84/0xf0
[  110.914979]  el0t_64_sync+0x18c/0x190
[  110.914996] ---[ end trace 0000000000000000 ]---
This happens because, although `prepare_fb` and `cleanup_fb` are
perfectly balanced, we cannot guarantee consistency in the check
plane-&gt;state-&gt;fb == state-&gt;fb. This means that sometimes we can increase
the refcount in `prepare_fb` and don't decrease it in `cleanup_fb`. The
opposite can also be true.
In fact, the struct drm_plane .state shouldn't be accessed directly
but instead, the `drm_atomic_get_new_plane_state()` helper function should
be used. So, we could stick to this check, but using
`drm_atomic_get_new_plane_state()`. But actually, this check is not re
---truncated---
CVE-2024-36953:In the Linux kernel, the following vulnerability has been resolved:
KVM: arm64: vgic-v2: Check for non-NULL vCPU in vgic_v2_parse_attr()
vgic_v2_parse_attr() is responsible for finding the vCPU that matches
the user-provided CPUID, which (of course) may not be valid. If the ID
is invalid, kvm_get_vcpu_by_id() returns NULL, which isn't handled
gracefully.
Similar to the GICv3 uaccess flow, check that kvm_get_vcpu_by_id()
actually returns something and fail the ioctl if not.
CVE-2024-35965:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix not validating setsockopt user input
Check user input length before copying data.
CVE-2024-36923:In the Linux kernel, the following vulnerability has been resolved:
fs/9p: fix uninitialized values during inode evict
If an iget fails due to not being able to retrieve information
from the server then the inode structure is only partially
initialized.  When the inode gets evicted, references to
uninitialized structures (like fscache cookies) were being
made.
This patch checks for a bad_inode before doing anything other
than clearing the inode from the cache.  Since the inode is
bad, it shouldn't have any state associated with it that needs
to be written back (and there really isn't a way to complete
those anyways).
CVE-2024-26936:In the Linux kernel, the following vulnerability has been resolved:
ksmbd: validate request buffer size in smb2_allocate_rsp_buf()
The response buffer should be allocated in smb2_allocate_rsp_buf
before validating request. But the fields in payload as well as smb2 header
is used in smb2_allocate_rsp_buf(). This patch add simple buffer size
validation to avoid potencial out-of-bounds in request buffer.
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.
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.
CVE-2024-26947:In the Linux kernel, the following vulnerability has been resolved:
ARM: 9359/1: flush: check if the folio is reserved for no-mapping addresses
Since commit a4d5613c4dc6 (&quot;arm: extend pfn_valid to take into account
freed memory map alignment&quot;) changes the semantics of pfn_valid() to check
presence of the memory map for a PFN. A valid page for an address which
is reserved but not mapped by the kernel[1], the system crashed during
some uio test with the following memory layout:
 node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff]
 node   0: [mem 0x00000000d0000000-0x00000000da1fffff]
 the uio layout is：0xc0900000, 0x100000
the crash backtrace like:
  Unable to handle kernel paging request at virtual address bff00000
  [...]
  CPU: 1 PID: 465 Comm: startapp.bin Tainted: G           O      5.10.0 #1
  Hardware name: Generic DT based system
  PC is at b15_flush_kern_dcache_area+0x24/0x3c
  LR is at __sync_icache_dcache+0x6c/0x98
  [...]
   (b15_flush_kern_dcache_area) from (__sync_icache_dcache+0x6c/0x98)
   (__sync_icache_dcache) from (set_pte_at+0x28/0x54)
   (set_pte_at) from (remap_pfn_range+0x1a0/0x274)
   (remap_pfn_range) from (uio_mmap+0x184/0x1b8 [uio])
   (uio_mmap [uio]) from (__mmap_region+0x264/0x5f4)
   (__mmap_region) from (__do_mmap_mm+0x3ec/0x440)
   (__do_mmap_mm) from (do_mmap+0x50/0x58)
   (do_mmap) from (vm_mmap_pgoff+0xfc/0x188)
   (vm_mmap_pgoff) from (ksys_mmap_pgoff+0xac/0xc4)
   (ksys_mmap_pgoff) from (ret_fast_syscall+0x0/0x5c)
  Code: e0801001 e2423001 e1c00003 f57ff04f (ee070f3e)
  ---[ end trace 09cf0734c3805d52 ]---
  Kernel panic - not syncing: Fatal exception
So check if PG_reserved was set to solve this issue.
[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/
CVE-2023-52810:In the Linux kernel, the following vulnerability has been resolved:
fs/jfs: Add check for negative db_l2nbperpage
l2nbperpage is log2(number of blks per page), and the minimum legal
value should be 0, not negative.
In the case of l2nbperpage being negative, an error will occur
when subsequently used as shift exponent.
Syzbot reported this bug:
UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12
shift exponent -16777216 is negative
CVE-2023-52791:In the Linux kernel, the following vulnerability has been resolved:
i2c: core: Run atomic i2c xfer when !preemptible
Since bae1d3a05a8b, i2c transfers are non-atomic if preemption is
disabled. However, non-atomic i2c transfers require preemption (e.g. in
wait_for_completion() while waiting for the DMA).
panic() calls preempt_disable_notrace() before calling
emergency_restart(). Therefore, if an i2c device is used for the
restart, the xfer should be atomic. This avoids warnings like:
[   12.667612] WARNING: CPU: 1 PID: 1 at kernel/rcu/tree_plugin.h:318 rcu_note_context_switch+0x33c/0x6b0
[   12.676926] Voluntary context switch within RCU read-side critical section!
...
[   12.742376]  schedule_timeout from wait_for_completion_timeout+0x90/0x114
[   12.749179]  wait_for_completion_timeout from tegra_i2c_wait_completion+0x40/0x70
...
[   12.994527]  atomic_notifier_call_chain from machine_restart+0x34/0x58
[   13.001050]  machine_restart from panic+0x2a8/0x32c
Use !preemptible() instead, which is basically the same check as
pre-v5.2.
CVE-2024-26935:In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix unremoved procfs host directory regression
Commit fc663711b944 (&quot;scsi: core: Remove the /proc/scsi/${proc_name}
directory earlier&quot;) fixed a bug related to modules loading/unloading, by
adding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that led
to a potential duplicate call to the hostdir_rm() routine, since it's also
called from scsi_host_dev_release(). That triggered a regression report,
which was then fixed by commit be03df3d4bfe (&quot;scsi: core: Fix a procfs host
directory removal regression&quot;). The fix just dropped the hostdir_rm() call
from dev_release().
But it happens that this proc directory is created on scsi_host_alloc(),
and that function &quot;pairs&quot; with scsi_host_dev_release(), while
scsi_remove_host() pairs with scsi_add_host(). In other words, it seems the
reason for removing the proc directory on dev_release() was meant to cover
cases in which a SCSI host structure was allocated, but the call to
scsi_add_host() didn't happen. And that pattern happens to exist in some
error paths, for example.
Syzkaller causes that by using USB raw gadget device, error'ing on
usb-storage driver, at usb_stor_probe2(). By checking that path, we can see
that the BadDevice label leads to a scsi_host_put() after a SCSI host
allocation, but there's no call to scsi_add_host() in such path. That leads
to messages like this in dmesg (and a leak of the SCSI host proc
structure):
usb-storage 4-1:87.51: USB Mass Storage device detected
proc_dir_entry 'scsi/usb-storage' already registered
WARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376
The proper fix seems to still call scsi_proc_hostdir_rm() on dev_release(),
but guard that with the state check for SHOST_CREATED; there is even a
comment in scsi_host_dev_release() detailing that: such conditional is
meant for cases where the SCSI host was allocated but there was no calls to
{add,remove}_host(), like the usb-storage case.
This is what we propose here and with that, the error path of usb-storage
does not trigger the warning anymore.
CVE-2024-35947:In the Linux kernel, the following vulnerability has been resolved:
dyndbg: fix old BUG_ON in &gt;control parser
Fix a BUG_ON from 2009.  Even if it looks &quot;unreachable&quot; (I didn't
really look), lets make sure by removing it, doing pr_err and return
-EINVAL instead.
CVE-2024-36969:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix division by zero in setup_dsc_config
When slice_height is 0, the division by slice_height in the calculation
of the number of slices will cause a division by zero driver crash. This
leaves the kernel in a state that requires a reboot. This patch adds a
check to avoid the division by zero.
The stack trace below is for the 6.8.4 Kernel. I reproduced the issue on
a Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitor
connected via Thunderbolt. The amdgpu driver crashed with this exception
when I rebooted the system with the monitor connected.
kernel: ? die (arch/x86/kernel/dumpstack.c:421 arch/x86/kernel/dumpstack.c:434 arch/x86/kernel/dumpstack.c:447)
kernel: ? do_trap (arch/x86/kernel/traps.c:113 arch/x86/kernel/traps.c:154)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? do_error_trap (./arch/x86/include/asm/traps.h:58 arch/x86/kernel/traps.c:175)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? exc_divide_error (arch/x86/kernel/traps.c:194 (discriminator 2))
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: ? asm_exc_divide_error (./arch/x86/include/asm/idtentry.h:548)
kernel: ? setup_dsc_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1053) amdgpu
kernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpu
After applying this patch, the driver no longer crashes when the monitor
is connected and the system is rebooted. I believe this is the same
issue reported for 3113.
CVE-2024-38601:In the Linux kernel, the following vulnerability has been resolved:
ring-buffer: Fix a race between readers and resize checks
The reader code in rb_get_reader_page() swaps a new reader page into the
ring buffer by doing cmpxchg on old-&gt;list.prev-&gt;next to point it to the
new page. Following that, if the operation is successful,
old-&gt;list.next-&gt;prev gets updated too. This means the underlying
doubly-linked list is temporarily inconsistent, page-&gt;prev-&gt;next or
page-&gt;next-&gt;prev might not be equal back to page for some page in the
ring buffer.
The resize operation in ring_buffer_resize() can be invoked in parallel.
It calls rb_check_pages() which can detect the described inconsistency
and stop further tracing:
[  190.271762] ------------[ cut here ]------------
[  190.271771] WARNING: CPU: 1 PID: 6186 at kernel/trace/ring_buffer.c:1467 rb_check_pages.isra.0+0x6a/0xa0
[  190.271789] Modules linked in: [...]
[  190.271991] Unloaded tainted modules: intel_uncore_frequency(E):1 skx_edac(E):1
[  190.272002] CPU: 1 PID: 6186 Comm: cmd.sh Kdump: loaded Tainted: G            E      6.9.0-rc6-default #5 158d3e1e6d0b091c34c3b96bfd99a1c58306d79f
[  190.272011] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.16.0-0-gd239552c-rebuilt.opensuse.org 04/01/2014
[  190.272015] RIP: 0010:rb_check_pages.isra.0+0x6a/0xa0
[  190.272023] Code: [...]
[  190.272028] RSP: 0018:ffff9c37463abb70 EFLAGS: 00010206
[  190.272034] RAX: ffff8eba04b6cb80 RBX: 0000000000000007 RCX: ffff8eba01f13d80
[  190.272038] RDX: ffff8eba01f130c0 RSI: ffff8eba04b6cd00 RDI: ffff8eba0004c700
[  190.272042] RBP: ffff8eba0004c700 R08: 0000000000010002 R09: 0000000000000000
[  190.272045] R10: 00000000ffff7f52 R11: ffff8eba7f600000 R12: ffff8eba0004c720
[  190.272049] R13: ffff8eba00223a00 R14: 0000000000000008 R15: ffff8eba067a8000
[  190.272053] FS:  00007f1bd64752c0(0000) GS:ffff8eba7f680000(0000) knlGS:0000000000000000
[  190.272057] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  190.272061] CR2: 00007f1bd6662590 CR3: 000000010291e001 CR4: 0000000000370ef0
[  190.272070] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  190.272073] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  190.272077] Call Trace:
[  190.272098]  &lt;TASK&gt;
[  190.272189]  ring_buffer_resize+0x2ab/0x460
[  190.272199]  __tracing_resize_ring_buffer.part.0+0x23/0xa0
[  190.272206]  tracing_resize_ring_buffer+0x65/0x90
[  190.272216]  tracing_entries_write+0x74/0xc0
[  190.272225]  vfs_write+0xf5/0x420
[  190.272248]  ksys_write+0x67/0xe0
[  190.272256]  do_syscall_64+0x82/0x170
[  190.272363]  entry_SYSCALL_64_after_hwframe+0x76/0x7e
[  190.272373] RIP: 0033:0x7f1bd657d263
[  190.272381] Code: [...]
[  190.272385] RSP: 002b:00007ffe72b643f8 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
[  190.272391] RAX: ffffffffffffffda RBX: 0000000000000002 RCX: 00007f1bd657d263
[  190.272395] RDX: 0000000000000002 RSI: 0000555a6eb538e0 RDI: 0000000000000001
[  190.272398] RBP: 0000555a6eb538e0 R08: 000000000000000a R09: 0000000000000000
[  190.272401] R10: 0000555a6eb55190 R11: 0000000000000246 R12: 00007f1bd6662500
[  190.272404] R13: 0000000000000002 R14: 00007f1bd6667c00 R15: 0000000000000002
[  190.272412]  &lt;/TASK&gt;
[  190.272414] ---[ end trace 0000000000000000 ]---
Note that ring_buffer_resize() calls rb_check_pages() only if the parent
trace_buffer has recording disabled. Recent commit d78ab792705c
(&quot;tracing: Stop current tracer when resizing buffer&quot;) causes that it is
now always the case which makes it more likely to experience this issue.
The window to hit this race is nonetheless very small. To help
reproducing it, one can add a delay loop in rb_get_reader_page():
 ret = rb_head_page_replace(reader, cpu_buffer-&gt;reader_page);
 if (!ret)
 	goto spin;
 for (unsigned i = 0; i &lt; 1U &lt;&lt; 26; i++)  /* inserted delay loop */
 	__asm__ __volatile__ (&quot;&quot; : : : &quot;memory&quot;);
 rb_list_head(reader-&gt;list.next)-&gt;prev = &amp;cpu_buffer-&gt;reader_page-&gt;list;
.. 
---truncated---
CVE-2024-38549:In the Linux kernel, the following vulnerability has been resolved:
drm/mediatek: Add 0 size check to mtk_drm_gem_obj
Add a check to mtk_drm_gem_init if we attempt to allocate a GEM object
of 0 bytes. Currently, no such check exists and the kernel will panic if
a userspace application attempts to allocate a 0x0 GBM buffer.
Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 and
verifying that we now return EINVAL.
CVE-2024-35811:In the Linux kernel, the following vulnerability has been resolved:
wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detach
This is the candidate patch of CVE-2023-47233 :
https://nvd.nist.gov/vuln/detail/CVE-2023-47233
In brcm80211 driver,it starts with the following invoking chain
to start init a timeout worker:
-&gt;brcmf_usb_probe
  -&gt;brcmf_usb_probe_cb
    -&gt;brcmf_attach
      -&gt;brcmf_bus_started
        -&gt;brcmf_cfg80211_attach
          -&gt;wl_init_priv
            -&gt;brcmf_init_escan
              -&gt;INIT_WORK(&amp;cfg-&gt;escan_timeout_work,
		  brcmf_cfg80211_escan_timeout_worker);
If we disconnect the USB by hotplug, it will call
brcmf_usb_disconnect to make cleanup. The invoking chain is :
brcmf_usb_disconnect
  -&gt;brcmf_usb_disconnect_cb
    -&gt;brcmf_detach
      -&gt;brcmf_cfg80211_detach
        -&gt;kfree(cfg);
While the timeout woker may still be running. This will cause
a use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.
Fix it by deleting the timer and canceling the worker in
brcmf_cfg80211_detach.
[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free]
CVE-2024-36978:In the Linux kernel, the following vulnerability has been resolved:
net: sched: sch_multiq: fix possible OOB write in multiq_tune()
q-&gt;bands will be assigned to qopt-&gt;bands to execute subsequent code logic
after kmalloc. So the old q-&gt;bands should not be used in kmalloc.
Otherwise, an out-of-bounds write will occur.
CVE-2024-38569:In the Linux kernel, the following vulnerability has been resolved:
drivers/perf: hisi_pcie: Fix out-of-bound access when valid event group
The perf tool allows users to create event groups through following
cmd [1], but the driver does not check whether the array index is out of
bounds when writing data to the event_group array. If the number of events
in an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory write
overflow of event_group array occurs.
Add array index check to fix the possible array out of bounds violation,
and return directly when write new events are written to array bounds.
There are 9 different events in an event_group.
[1] perf stat -e '{pmu/event1/, ... ,pmu/event9/}'
CVE-2024-38538:In the Linux kernel, the following vulnerability has been resolved:
net: bridge: xmit: make sure we have at least eth header len bytes
syzbot triggered an uninit value[1] error in bridge device's xmit path
by sending a short (less than ETH_HLEN bytes) skb. To fix it check if
we can actually pull that amount instead of assuming.
Tested with dropwatch:
 drop at: br_dev_xmit+0xb93/0x12d0 [bridge] (0xffffffffc06739b3)
 origin: software
 timestamp: Mon May 13 11:31:53 2024 778214037 nsec
 protocol: 0x88a8
 length: 2
 original length: 2
 drop reason: PKT_TOO_SMALL
[1]
BUG: KMSAN: uninit-value in br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
 br_dev_xmit+0x61d/0x1cb0 net/bridge/br_device.c:65
 __netdev_start_xmit include/linux/netdevice.h:4903 [inline]
 netdev_start_xmit include/linux/netdevice.h:4917 [inline]
 xmit_one net/core/dev.c:3531 [inline]
 dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3547
 __dev_queue_xmit+0x34db/0x5350 net/core/dev.c:4341
 dev_queue_xmit include/linux/netdevice.h:3091 [inline]
 __bpf_tx_skb net/core/filter.c:2136 [inline]
 __bpf_redirect_common net/core/filter.c:2180 [inline]
 __bpf_redirect+0x14a6/0x1620 net/core/filter.c:2187
 ____bpf_clone_redirect net/core/filter.c:2460 [inline]
 bpf_clone_redirect+0x328/0x470 net/core/filter.c:2432
 ___bpf_prog_run+0x13fe/0xe0f0 kernel/bpf/core.c:1997
 __bpf_prog_run512+0xb5/0xe0 kernel/bpf/core.c:2238
 bpf_dispatcher_nop_func include/linux/bpf.h:1234 [inline]
 __bpf_prog_run include/linux/filter.h:657 [inline]
 bpf_prog_run include/linux/filter.h:664 [inline]
 bpf_test_run+0x499/0xc30 net/bpf/test_run.c:425
 bpf_prog_test_run_skb+0x14ea/0x1f20 net/bpf/test_run.c:1058
 bpf_prog_test_run+0x6b7/0xad0 kernel/bpf/syscall.c:4269
 __sys_bpf+0x6aa/0xd90 kernel/bpf/syscall.c:5678
 __do_sys_bpf kernel/bpf/syscall.c:5767 [inline]
 __se_sys_bpf kernel/bpf/syscall.c:5765 [inline]
 __x64_sys_bpf+0xa0/0xe0 kernel/bpf/syscall.c:5765
 x64_sys_call+0x96b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:322
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xcf/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2024-38596:In the Linux kernel, the following vulnerability has been resolved:
af_unix: Fix data races in unix_release_sock/unix_stream_sendmsg
A data-race condition has been identified in af_unix. In one data path,
the write function unix_release_sock() atomically writes to
sk-&gt;sk_shutdown using WRITE_ONCE. However, on the reader side,
unix_stream_sendmsg() does not read it atomically. Consequently, this
issue is causing the following KCSAN splat to occur:
	BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg
	write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:
	unix_release_sock (net/unix/af_unix.c:640)
	unix_release (net/unix/af_unix.c:1050)
	sock_close (net/socket.c:659 net/socket.c:1421)
	__fput (fs/file_table.c:422)
	__fput_sync (fs/file_table.c:508)
	__se_sys_close (fs/open.c:1559 fs/open.c:1541)
	__x64_sys_close (fs/open.c:1541)
	x64_sys_call (arch/x86/entry/syscall_64.c:33)
	do_syscall_64 (arch/x86/entry/common.c:?)
	entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
	read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:
	unix_stream_sendmsg (net/unix/af_unix.c:2273)
	__sock_sendmsg (net/socket.c:730 net/socket.c:745)
	____sys_sendmsg (net/socket.c:2584)
	__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)
	__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)
	x64_sys_call (arch/x86/entry/syscall_64.c:33)
	do_syscall_64 (arch/x86/entry/common.c:?)
	entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
	value changed: 0x01 -&gt; 0x03
The line numbers are related to commit dd5a440a31fa (&quot;Linux 6.9-rc7&quot;).
Commit e1d09c2c2f57 (&quot;af_unix: Fix data races around sk-&gt;sk_shutdown.&quot;)
addressed a comparable issue in the past regarding sk-&gt;sk_shutdown.
However, it overlooked resolving this particular data path.
This patch only offending unix_stream_sendmsg() function, since the
other reads seem to be protected by unix_state_lock() as discussed in
CVE-2024-36974:In the Linux kernel, the following vulnerability has been resolved:
net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAP
If one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,
taprio_parse_mqprio_opt() must validate it, or userspace
can inject arbitrary data to the kernel, the second time
taprio_change() is called.
First call (with valid attributes) sets dev-&gt;num_tc
to a non zero value.
Second call (with arbitrary mqprio attributes)
returns early from taprio_parse_mqprio_opt()
and bad things can happen.
CVE-2023-52696:In the Linux kernel, the following vulnerability has been resolved:
powerpc/powernv: Add a null pointer check in opal_powercap_init()
kasprintf() returns a pointer to dynamically allocated memory
which can be NULL upon failure.
CVE-2024-26661:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL test for 'timing generator' in 'dcn21_set_pipe()'
In &quot;u32 otg_inst = pipe_ctx-&gt;stream_res.tg-&gt;inst;&quot;
pipe_ctx-&gt;stream_res.tg could be NULL, it is relying on the caller to
ensure the tg is not NULL.
CVE-2024-38634:In the Linux kernel, the following vulnerability has been resolved:
serial: max3100: Lock port-&gt;lock when calling uart_handle_cts_change()
uart_handle_cts_change() has to be called with port lock taken,
Since we run it in a separate work, the lock may not be taken at
the time of running. Make sure that it's taken by explicitly doing
that. Without it we got a splat:
  WARNING: CPU: 0 PID: 10 at drivers/tty/serial/serial_core.c:3491 uart_handle_cts_change+0xa6/0xb0
  ...
  Workqueue: max3100-0 max3100_work [max3100]
  RIP: 0010:uart_handle_cts_change+0xa6/0xb0
  ...
   max3100_handlerx+0xc5/0x110 [max3100]
   max3100_work+0x12a/0x340 [max3100]
CVE-2024-38605:In the Linux kernel, the following vulnerability has been resolved:
ALSA: core: Fix NULL module pointer assignment at card init
The commit 81033c6b584b (&quot;ALSA: core: Warn on empty module&quot;)
introduced a WARN_ON() for a NULL module pointer passed at snd_card
object creation, and it also wraps the code around it with '#ifdef
MODULE'.  This works in most cases, but the devils are always in
details.  &quot;MODULE&quot; is defined when the target code (i.e. the sound
core) is built as a module; but this doesn't mean that the caller is
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),
the passed module pointer is ignored even if it's non-NULL, and
card-&gt;module remains as NULL.  This would result in the missing module
reference up/down at the device open/close, leading to a race with the
code execution after the module removal.
For addressing the bug, move the assignment of card-&gt;module again out
of ifdef.  The WARN_ON() is still wrapped with ifdef because the
module can be really NULL when all sound drivers are built-in.
Note that we keep 'ifdef MODULE' for WARN_ON(), otherwise it would
lead to a false-positive NULL module check.  Admittedly it won't catch
perfectly, i.e. no check is performed when CONFIG_SND=y.  But, it's no
real problem as it's only for debugging, and the condition is pretty
rare.
CVE-2024-38545:In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix UAF for cq async event
The refcount of CQ is not protected by locks. When CQ asynchronous
events and CQ destruction are concurrent, CQ may have been released,
which will cause UAF.
Use the xa_lock() to protect the CQ refcount.
CVE-2024-38633:In the Linux kernel, the following vulnerability has been resolved:
serial: max3100: Update uart_driver_registered on driver removal
The removal of the last MAX3100 device triggers the removal of
the driver. However, code doesn't update the respective global
variable and after insmod — rmmod — insmod cycle the kernel
oopses:
  max3100 spi-PRP0001:01: max3100_probe: adding port 0
  BUG: kernel NULL pointer dereference, address: 0000000000000408
  ...
  RIP: 0010:serial_core_register_port+0xa0/0x840
  ...
   max3100_probe+0x1b6/0x280 [max3100]
   spi_probe+0x8d/0xb0
Update the actual state so next time UART driver will be registered
again.
Hugo also noticed, that the error path in the probe also affected
by having the variable set, and not cleared. Instead of clearing it
move the assignment after the successfull uart_register_driver() call.
CVE-2024-38632:In the Linux kernel, the following vulnerability has been resolved:
vfio/pci: fix potential memory leak in vfio_intx_enable()
If vfio_irq_ctx_alloc() failed will lead to 'name' memory leak.
CVE-2024-38591:In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Fix deadlock on SRQ async events.
xa_lock for SRQ table may be required in AEQ. Use xa_store_irq()/
xa_erase_irq() to avoid deadlock.
CVE-2024-31076:In the Linux kernel, the following vulnerability has been resolved:
genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offline
The absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness of
interrupt affinity reconfiguration via procfs. Instead, the change is
deferred until the next instance of the interrupt being triggered on the
original CPU.
When the interrupt next triggers on the original CPU, the new affinity is
enforced within __irq_move_irq(). A vector is allocated from the new CPU,
but the old vector on the original CPU remains and is not immediately
reclaimed. Instead, apicd-&gt;move_in_progress is flagged, and the reclaiming
process is delayed until the next trigger of the interrupt on the new CPU.
Upon the subsequent triggering of the interrupt on the new CPU,
irq_complete_move() adds a task to the old CPU's vector_cleanup list if it
remains online. Subsequently, the timer on the old CPU iterates over its
vector_cleanup list, reclaiming old vectors.
However, a rare scenario arises if the old CPU is outgoing before the
interrupt triggers again on the new CPU.
In that case irq_force_complete_move() is not invoked on the outgoing CPU
to reclaim the old apicd-&gt;prev_vector because the interrupt isn't currently
affine to the outgoing CPU, and irq_needs_fixup() returns false. Even
though __vector_schedule_cleanup() is later called on the new CPU, it
doesn't reclaim apicd-&gt;prev_vector; instead, it simply resets both
apicd-&gt;move_in_progress and apicd-&gt;prev_vector to 0.
As a result, the vector remains unreclaimed in vector_matrix, leading to a
CPU vector leak.
To address this issue, move the invocation of irq_force_complete_move()
before the irq_needs_fixup() call to reclaim apicd-&gt;prev_vector, if the
interrupt is currently or used to be affine to the outgoing CPU.
Additionally, reclaim the vector in __vector_schedule_cleanup() as well,
following a warning message, although theoretically it should never see
apicd-&gt;move_in_progress with apicd-&gt;prev_cpu pointing to an offline CPU.
CVE-2024-35955:In the Linux kernel, the following vulnerability has been resolved:
kprobes: Fix possible use-after-free issue on kprobe registration
When unloading a module, its state is changing MODULE_STATE_LIVE -&gt;
 MODULE_STATE_GOING -&gt; MODULE_STATE_UNFORMED. Each change will take
a time. `is_module_text_address()` and `__module_text_address()`
works with MODULE_STATE_LIVE and MODULE_STATE_GOING.
If we use `is_module_text_address()` and `__module_text_address()`
separately, there is a chance that the first one is succeeded but the
next one is failed because module-&gt;state becomes MODULE_STATE_UNFORMED
between those operations.
In `check_kprobe_address_safe()`, if the second `__module_text_address()`
is failed, that is ignored because it expected a kernel_text address.
But it may have failed simply because module-&gt;state has been changed
to MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modify
non-exist module text address (use-after-free).
To fix this problem, we should not use separated `is_module_text_address()`
and `__module_text_address()`, but use only `__module_text_address()`
once and do `try_module_get(module)` which is only available with
MODULE_STATE_LIVE.
CVE-2021-47381:In the Linux kernel, the following vulnerability has been resolved:
ASoC: SOF: Fix DSP oops stack dump output contents
Fix @buf arg given to hex_dump_to_buffer() and stack address used
in dump error output.
CVE-2024-38555:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Discard command completions in internal error
Fix use after free when FW completion arrives while device is in
internal error state. Avoid calling completion handler in this case,
since the device will flush the command interface and trigger all
completions manually.
Kernel log:
------------[ cut here ]------------
refcount_t: underflow; use-after-free.
...
RIP: 0010:refcount_warn_saturate+0xd8/0xe0
...
Call Trace:
&lt;IRQ&gt;
? __warn+0x79/0x120
? refcount_warn_saturate+0xd8/0xe0
? report_bug+0x17c/0x190
? handle_bug+0x3c/0x60
? exc_invalid_op+0x14/0x70
? asm_exc_invalid_op+0x16/0x20
? refcount_warn_saturate+0xd8/0xe0
cmd_ent_put+0x13b/0x160 [mlx5_core]
mlx5_cmd_comp_handler+0x5f9/0x670 [mlx5_core]
cmd_comp_notifier+0x1f/0x30 [mlx5_core]
notifier_call_chain+0x35/0xb0
atomic_notifier_call_chain+0x16/0x20
mlx5_eq_async_int+0xf6/0x290 [mlx5_core]
notifier_call_chain+0x35/0xb0
atomic_notifier_call_chain+0x16/0x20
irq_int_handler+0x19/0x30 [mlx5_core]
__handle_irq_event_percpu+0x4b/0x160
handle_irq_event+0x2e/0x80
handle_edge_irq+0x98/0x230
__common_interrupt+0x3b/0xa0
common_interrupt+0x7b/0xa0
&lt;/IRQ&gt;
&lt;TASK&gt;
asm_common_interrupt+0x22/0x40
CVE-2024-38577:In the Linux kernel, the following vulnerability has been resolved:
rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflow
There is a possibility of buffer overflow in
show_rcu_tasks_trace_gp_kthread() if counters, passed
to sprintf() are huge. Counter numbers, needed for this
are unrealistically high, but buffer overflow is still
possible.
Use snprintf() with buffer size instead of sprintf().
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-38599:In the Linux kernel, the following vulnerability has been resolved:
jffs2: prevent xattr node from overflowing the eraseblock
Add a check to make sure that the requested xattr node size is no larger
than the eraseblock minus the cleanmarker.
Unlike the usual inode nodes, the xattr nodes aren't split into parts
and spread across multiple eraseblocks, which means that a xattr node
must not occupy more than one eraseblock. If the requested xattr value is
too large, the xattr node can spill onto the next eraseblock, overwriting
the nodes and causing errors such as:
jffs2: argh. node added in wrong place at 0x0000b050(2)
jffs2: nextblock 0x0000a000, expected at 0000b00c
jffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,
read=0xfc892c93, calc=0x000000
jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failed
at 0x01e00c. {848f,2fc4,0fef511f,59a3d171}
jffs2: Node at 0x0000000c with length 0x00001044 would run over the
end of the erase block
jffs2: Perhaps the file system was created with the wrong erase size?
jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found
at 0x00000010: 0x1044 instead
This breaks the filesystem and can lead to KASAN crashes such as:
BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0
Read of size 4 at addr ffff88802c31e914 by task repro/830
CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS Arch Linux 1.16.3-1-1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0xc6/0x120
 print_report+0xc4/0x620
 ? __virt_addr_valid+0x308/0x5b0
 kasan_report+0xc1/0xf0
 ? jffs2_sum_add_kvec+0x125e/0x15d0
 ? jffs2_sum_add_kvec+0x125e/0x15d0
 jffs2_sum_add_kvec+0x125e/0x15d0
 jffs2_flash_direct_writev+0xa8/0xd0
 jffs2_flash_writev+0x9c9/0xef0
 ? __x64_sys_setxattr+0xc4/0x160
 ? do_syscall_64+0x69/0x140
 ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
 [...]
Found by Linux Verification Center (linuxtesting.org) with Syzkaller.
CVE-2024-38564:In the Linux kernel, the following vulnerability has been resolved:
bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATE
bpf_prog_attach uses attach_type_to_prog_type to enforce proper
attach type for BPF_PROG_TYPE_CGROUP_SKB. link_create uses
bpf_prog_get and relies on bpf_prog_attach_check_attach_type
to properly verify prog_type &lt;&gt; attach_type association.
Add missing attach_type enforcement for the link_create case.
Otherwise, it's currently possible to attach cgroup_skb prog
types to other cgroup hooks.
CVE-2024-38630:In the Linux kernel, the following vulnerability has been resolved:
watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_trigger
When the cpu5wdt module is removing, the origin code uses del_timer() to
de-activate the timer. If the timer handler is running, del_timer() could
not stop it and will return directly. If the port region is released by
release_region() and then the timer handler cpu5wdt_trigger() calls outb()
to write into the region that is released, the use-after-free bug will
happen.
Change del_timer() to timer_shutdown_sync() in order that the timer handler
could be finished before the port region is released.
CVE-2024-38624:In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Use 64 bit variable to avoid 32 bit overflow
For example, in the expression:
	vbo = 2 * vbo + skip
CVE-2024-38589:In the Linux kernel, the following vulnerability has been resolved:
netrom: fix possible dead-lock in nr_rt_ioctl()
syzbot loves netrom, and found a possible deadlock in nr_rt_ioctl [1]
Make sure we always acquire nr_node_list_lock before nr_node_lock(nr_node)
[1]
WARNING: possible circular locking dependency detected
6.9.0-rc7-syzkaller-02147-g654de42f3fc6 #0 Not tainted
------------------------------------------------------
syz-executor350/5129 is trying to acquire lock:
 ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
 ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_node_lock include/net/netrom.h:152 [inline]
 ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:464 [inline]
 ffff8880186e2070 (&amp;nr_node-&gt;node_lock){+...}-{2:2}, at: nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
but task is already holding lock:
 ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
 ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
 ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_rt_ioctl+0x10a/0x1090 net/netrom/nr_route.c:697
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-&gt; #1 (nr_node_list_lock){+...}-{2:2}:
        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
        __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
        _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
        spin_lock_bh include/linux/spinlock.h:356 [inline]
        nr_remove_node net/netrom/nr_route.c:299 [inline]
        nr_del_node+0x4b4/0x820 net/netrom/nr_route.c:355
        nr_rt_ioctl+0xa95/0x1090 net/netrom/nr_route.c:683
        sock_do_ioctl+0x158/0x460 net/socket.c:1222
        sock_ioctl+0x629/0x8e0 net/socket.c:1341
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:904 [inline]
        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
-&gt; #0 (&amp;nr_node-&gt;node_lock){+...}-{2:2}:
        check_prev_add kernel/locking/lockdep.c:3134 [inline]
        check_prevs_add kernel/locking/lockdep.c:3253 [inline]
        validate_chain+0x18cb/0x58e0 kernel/locking/lockdep.c:3869
        __lock_acquire+0x1346/0x1fd0 kernel/locking/lockdep.c:5137
        lock_acquire+0x1ed/0x550 kernel/locking/lockdep.c:5754
        __raw_spin_lock_bh include/linux/spinlock_api_smp.h:126 [inline]
        _raw_spin_lock_bh+0x35/0x50 kernel/locking/spinlock.c:178
        spin_lock_bh include/linux/spinlock.h:356 [inline]
        nr_node_lock include/net/netrom.h:152 [inline]
        nr_dec_obs net/netrom/nr_route.c:464 [inline]
        nr_rt_ioctl+0x1bb/0x1090 net/netrom/nr_route.c:697
        sock_do_ioctl+0x158/0x460 net/socket.c:1222
        sock_ioctl+0x629/0x8e0 net/socket.c:1341
        vfs_ioctl fs/ioctl.c:51 [inline]
        __do_sys_ioctl fs/ioctl.c:904 [inline]
        __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:890
        do_syscall_x64 arch/x86/entry/common.c:52 [inline]
        do_syscall_64+0xf5/0x240 arch/x86/entry/common.c:83
       entry_SYSCALL_64_after_hwframe+0x77/0x7f
other info that might help us debug this:
 Possible unsafe locking scenario:
       CPU0                    CPU1
       ----                    ----
  lock(nr_node_list_lock);
                               lock(&amp;nr_node-&gt;node_lock);
                               lock(nr_node_list_lock);
  lock(&amp;nr_node-&gt;node_lock);
 *** DEADLOCK ***
1 lock held by syz-executor350/5129:
  #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: spin_lock_bh include/linux/spinlock.h:356 [inline]
  #0: ffffffff8f7053b8 (nr_node_list_lock){+...}-{2:2}, at: nr_dec_obs net/netrom/nr_route.c:462 [inline]
  #0: ffffffff8f70
---truncated---
CVE-2024-35969:In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addr
Although ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, it
still means hlist_for_each_entry_rcu can return an item that got removed
from the list. The memory itself of such item is not freed thanks to RCU
but nothing guarantees the actual content of the memory is sane.
In particular, the reference count can be zero. This can happen if
ipv6_del_addr is called in parallel. ipv6_del_addr removes the entry
from inet6_addr_lst (hlist_del_init_rcu(&amp;ifp-&gt;addr_lst)) and drops all
references (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enough
timing, this can happen:
1. In ipv6_get_ifaddr, hlist_for_each_entry_rcu returns an entry.
2. Then, the whole ipv6_del_addr is executed for the given entry. The
   reference count drops to zero and kfree_rcu is scheduled.
3. ipv6_get_ifaddr continues and tries to increments the reference count
   (in6_ifa_hold).
4. The rcu is unlocked and the entry is freed.
5. The freed entry is returned.
Prevent increasing of the reference count in such case. The name
in6_ifa_hold_safe is chosen to mimic the existing fib6_info_hold_safe.
[   41.506330] refcount_t: addition on 0; use-after-free.
[   41.506760] WARNING: CPU: 0 PID: 595 at lib/refcount.c:25 refcount_warn_saturate+0xa5/0x130
[   41.507413] Modules linked in: veth bridge stp llc
[   41.507821] CPU: 0 PID: 595 Comm: python3 Not tainted 6.9.0-rc2.main-00208-g49563be82afa #14
[   41.508479] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
[   41.509163] RIP: 0010:refcount_warn_saturate+0xa5/0x130
[   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
[   41.510956] RSP: 0018:ffffbda3c026baf0 EFLAGS: 00010282
[   41.511368] RAX: 0000000000000000 RBX: ffff9e9c46914800 RCX: 0000000000000000
[   41.511910] RDX: ffff9e9c7ec29c00 RSI: ffff9e9c7ec1c900 RDI: ffff9e9c7ec1c900
[   41.512445] RBP: ffff9e9c43660c9c R08: 0000000000009ffb R09: 00000000ffffdfff
[   41.512998] R10: 00000000ffffdfff R11: ffffffff8ca58a40 R12: ffff9e9c4339a000
[   41.513534] R13: 0000000000000001 R14: ffff9e9c438a0000 R15: ffffbda3c026bb48
[   41.514086] FS:  00007fbc4cda1740(0000) GS:ffff9e9c7ec00000(0000) knlGS:0000000000000000
[   41.514726] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   41.515176] CR2: 000056233b337d88 CR3: 000000000376e006 CR4: 0000000000370ef0
[   41.515713] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   41.516252] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   41.516799] Call Trace:
[   41.517037]  &lt;TASK&gt;
[   41.517249]  ? __warn+0x7b/0x120
[   41.517535]  ? refcount_warn_saturate+0xa5/0x130
[   41.517923]  ? report_bug+0x164/0x190
[   41.518240]  ? handle_bug+0x3d/0x70
[   41.518541]  ? exc_invalid_op+0x17/0x70
[   41.520972]  ? asm_exc_invalid_op+0x1a/0x20
[   41.521325]  ? refcount_warn_saturate+0xa5/0x130
[   41.521708]  ipv6_get_ifaddr+0xda/0xe0
[   41.522035]  inet6_rtm_getaddr+0x342/0x3f0
[   41.522376]  ? __pfx_inet6_rtm_getaddr+0x10/0x10
[   41.522758]  rtnetlink_rcv_msg+0x334/0x3d0
[   41.523102]  ? netlink_unicast+0x30f/0x390
[   41.523445]  ? __pfx_rtnetlink_rcv_msg+0x10/0x10
[   41.523832]  netlink_rcv_skb+0x53/0x100
[   41.524157]  netlink_unicast+0x23b/0x390
[   41.524484]  netlink_sendmsg+0x1f2/0x440
[   41.524826]  __sys_sendto+0x1d8/0x1f0
[   41.525145]  __x64_sys_sendto+0x1f/0x30
[   41.525467]  do_syscall_64+0xa5/0x1b0
[   41.525794]  entry_SYSCALL_64_after_hwframe+0x72/0x7a
[   41.526213] RIP: 0033:0x7fbc4cfcea9a
[   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
[   41.527942] RSP: 002b:00007f
---truncated---
CVE-2024-38544:In the Linux kernel, the following vulnerability has been resolved:
RDMA/rxe: Fix seg fault in rxe_comp_queue_pkt
In rxe_comp_queue_pkt() an incoming response packet skb is enqueued to the
resp_pkts queue and then a decision is made whether to run the completer
task inline or schedule it. Finally the skb is dereferenced to bump a 'hw'
performance counter. This is wrong because if the completer task is
already running in a separate thread it may have already processed the skb
and freed it which can cause a seg fault.  This has been observed
infrequently in testing at high scale.
This patch fixes this by changing the order of enqueuing the packet until
after the counter is accessed.
CVE-2022-48772:In the Linux kernel, the following vulnerability has been resolved:
media: lgdt3306a: Add a check against null-pointer-def
The driver should check whether the client provides the platform_data.
The following log reveals it:
[   29.610324] BUG: KASAN: null-ptr-deref in kmemdup+0x30/0x40
[   29.610730] Read of size 40 at addr 0000000000000000 by task bash/414
[   29.612820] Call Trace:
[   29.613030]  &lt;TASK&gt;
[   29.613201]  dump_stack_lvl+0x56/0x6f
[   29.613496]  ? kmemdup+0x30/0x40
[   29.613754]  print_report.cold+0x494/0x6b7
[   29.614082]  ? kmemdup+0x30/0x40
[   29.614340]  kasan_report+0x8a/0x190
[   29.614628]  ? kmemdup+0x30/0x40
[   29.614888]  kasan_check_range+0x14d/0x1d0
[   29.615213]  memcpy+0x20/0x60
[   29.615454]  kmemdup+0x30/0x40
[   29.615700]  lgdt3306a_probe+0x52/0x310
[   29.616339]  i2c_device_probe+0x951/0xa90
CVE-2024-39276:In the Linux kernel, the following vulnerability has been resolved:
ext4: fix mb_cache_entry's e_refcnt leak in ext4_xattr_block_cache_find()
Syzbot reports a warning as follows:
============================================
WARNING: CPU: 0 PID: 5075 at fs/mbcache.c:419 mb_cache_destroy+0x224/0x290
Modules linked in:
CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7
RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419
Call Trace:
 &lt;TASK&gt;
 ext4_put_super+0x6d4/0xcd0 fs/ext4/super.c:1375
 generic_shutdown_super+0x136/0x2d0 fs/super.c:641
 kill_block_super+0x44/0x90 fs/super.c:1675
 ext4_kill_sb+0x68/0xa0 fs/ext4/super.c:7327
[...]
============================================
This is because when finding an entry in ext4_xattr_block_cache_find(), if
ext4_sb_bread() returns -ENOMEM, the ce's e_refcnt, which has already grown
in the __entry_find(), won't be put away, and eventually trigger the above
issue in mb_cache_destroy() due to reference count leakage.
So call mb_cache_entry_put() on the -ENOMEM error branch as a quick fix.
CVE-2024-38625:In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Check 'folio' pointer for NULL
It can be NULL if bmap is called.
CVE-2024-38552:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix potential index out of bounds in color transformation function
Fixes index out of bounds issue in the color transformation function.
The issue could occur when the index 'i' exceeds the number of transfer
function points (TRANSFER_FUNC_POINTS).
The fix adds a check to ensure 'i' is within bounds before accessing the
transfer function points. If 'i' is out of bounds, an error message is
logged and the function returns false to indicate an error.
Reported by smatch:
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:405 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.red' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.green' 1025 &lt;= s32max
drivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow 'output_tf-&gt;tf_pts.blue' 1025 &lt;= s32max
CVE-2024-37354:In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix crash on racing fsync and size-extending write into prealloc
We have been seeing crashes on duplicate keys in
btrfs_set_item_key_safe():
  BTRFS critical (device vdb): slot 4 key (450 108 8192) new key (450 108 8192)
  ------------[ cut here ]------------
  kernel BUG at fs/btrfs/ctree.c:2620!
  invalid opcode: 0000 [#1] PREEMPT SMP PTI
  CPU: 0 PID: 3139 Comm: xfs_io Kdump: loaded Not tainted 6.9.0 #6
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
  RIP: 0010:btrfs_set_item_key_safe+0x11f/0x290 [btrfs]
With the following stack trace:
  #0  btrfs_set_item_key_safe (fs/btrfs/ctree.c:2620:4)
  #1  btrfs_drop_extents (fs/btrfs/file.c:411:4)
  #2  log_one_extent (fs/btrfs/tree-log.c:4732:9)
  #3  btrfs_log_changed_extents (fs/btrfs/tree-log.c:4955:9)
  #4  btrfs_log_inode (fs/btrfs/tree-log.c:6626:9)
  #5  btrfs_log_inode_parent (fs/btrfs/tree-log.c:7070:8)
  #6  btrfs_log_dentry_safe (fs/btrfs/tree-log.c:7171:8)
  #7  btrfs_sync_file (fs/btrfs/file.c:1933:8)
  #8  vfs_fsync_range (fs/sync.c:188:9)
  #9  vfs_fsync (fs/sync.c:202:9)
  #10 do_fsync (fs/sync.c:212:9)
  #11 __do_sys_fdatasync (fs/sync.c:225:9)
  #12 __se_sys_fdatasync (fs/sync.c:223:1)
  #13 __x64_sys_fdatasync (fs/sync.c:223:1)
  #14 do_syscall_x64 (arch/x86/entry/common.c:52:14)
  #15 do_syscall_64 (arch/x86/entry/common.c:83:7)
  #16 entry_SYSCALL_64+0xaf/0x14c (arch/x86/entry/entry_64.S:121)
So we're logging a changed extent from fsync, which is splitting an
extent in the log tree. But this split part already exists in the tree,
triggering the BUG().
This is the state of the log tree at the time of the crash, dumped with
drgn (https://github.com/osandov/drgn/blob/main/contrib/btrfs_tree.py)
to get more details than btrfs_print_leaf() gives us:
  &gt;&gt;&gt; print_extent_buffer(prog.crashed_thread().stack_trace()[0][&quot;eb&quot;])
  leaf 33439744 level 0 items 72 generation 9 owner 18446744073709551610
  leaf 33439744 flags 0x100000000000000
  fs uuid e5bd3946-400c-4223-8923-190ef1f18677
  chunk uuid d58cb17e-6d02-494a-829a-18b7d8a399da
          item 0 key (450 INODE_ITEM 0) itemoff 16123 itemsize 160
                  generation 7 transid 9 size 8192 nbytes 8473563889606862198
                  block group 0 mode 100600 links 1 uid 0 gid 0 rdev 0
                  sequence 204 flags 0x10(PREALLOC)
                  atime 1716417703.220000000 (2024-05-22 15:41:43)
                  ctime 1716417704.983333333 (2024-05-22 15:41:44)
                  mtime 1716417704.983333333 (2024-05-22 15:41:44)
                  otime 17592186044416.000000000 (559444-03-08 01:40:16)
          item 1 key (450 INODE_REF 256) itemoff 16110 itemsize 13
                  index 195 namelen 3 name: 193
          item 2 key (450 XATTR_ITEM 1640047104) itemoff 16073 itemsize 37
                  location key (0 UNKNOWN.0 0) type XATTR
                  transid 7 data_len 1 name_len 6
                  name: user.a
                  data a
          item 3 key (450 EXTENT_DATA 0) itemoff 16020 itemsize 53
                  generation 9 type 1 (regular)
                  extent data disk byte 303144960 nr 12288
                  extent data offset 0 nr 4096 ram 12288
                  extent compression 0 (none)
          item 4 key (450 EXTENT_DATA 4096) itemoff 15967 itemsize 53
                  generation 9 type 2 (prealloc)
                  prealloc data disk byte 303144960 nr 12288
                  prealloc data offset 4096 nr 8192
          item 5 key (450 EXTENT_DATA 8192) itemoff 15914 itemsize 53
                  generation 9 type 2 (prealloc)
                  prealloc data disk byte 303144960 nr 12288
                  prealloc data offset 8192 nr 4096
  ...
So the real problem happened earlier: notice that items 4 (4k-12k) and 5
(8k-12k) overlap. Both are prealloc extents. Item 4 straddles i_size and
item 5 starts at i_size.
Here is the state of 
---truncated---
CVE-2024-38541:In the Linux kernel, the following vulnerability has been resolved:
of: module: add buffer overflow check in of_modalias()
In of_modalias(), if the buffer happens to be too small even for the 1st
snprintf() call, the len parameter will become negative and str parameter
(if not NULL initially) will point beyond the buffer's end. Add the buffer
overflow check after the 1st snprintf() call and fix such check after the
strlen() call (accounting for the terminating NUL char).
CVE-2024-38661:In the Linux kernel, the following vulnerability has been resolved:
s390/ap: Fix crash in AP internal function modify_bitmap()
A system crash like this
  Failing address: 200000cb7df6f000 TEID: 200000cb7df6f403
  Fault in home space mode while using kernel ASCE.
  AS:00000002d71bc007 R3:00000003fe5b8007 S:000000011a446000 P:000000015660c13d
  Oops: 0038 ilc:3 [#1] PREEMPT SMP
  Modules linked in: mlx5_ib ...
  CPU: 8 PID: 7556 Comm: bash Not tainted 6.9.0-rc7 #8
  Hardware name: IBM 3931 A01 704 (LPAR)
  Krnl PSW : 0704e00180000000 0000014b75e7b606 (ap_parse_bitmap_str+0x10e/0x1f8)
  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
  Krnl GPRS: 0000000000000001 ffffffffffffffc0 0000000000000001 00000048f96b75d3
  000000cb00000100 ffffffffffffffff ffffffffffffffff 000000cb7df6fce0
  000000cb7df6fce0 00000000ffffffff 000000000000002b 00000048ffffffff
  000003ff9b2dbc80 200000cb7df6fcd8 0000014bffffffc0 000000cb7df6fbc8
  Krnl Code: 0000014b75e7b5fc: a7840047            brc     8,0000014b75e7b68a
  0000014b75e7b600: 18b2                lr      %r11,%r2
  #0000014b75e7b602: a7f4000a            brc     15,0000014b75e7b616
  &gt;0000014b75e7b606: eb22d00000e6        laog    %r2,%r2,0(%r13)
  0000014b75e7b60c: a7680001            lhi     %r6,1
  0000014b75e7b610: 187b                lr      %r7,%r11
  0000014b75e7b612: 84960021            brxh    %r9,%r6,0000014b75e7b654
  0000014b75e7b616: 18e9                lr      %r14,%r9
  Call Trace:
  [&lt;0000014b75e7b606&gt;] ap_parse_bitmap_str+0x10e/0x1f8
  ([&lt;0000014b75e7b5dc&gt;] ap_parse_bitmap_str+0xe4/0x1f8)
  [&lt;0000014b75e7b758&gt;] apmask_store+0x68/0x140
  [&lt;0000014b75679196&gt;] kernfs_fop_write_iter+0x14e/0x1e8
  [&lt;0000014b75598524&gt;] vfs_write+0x1b4/0x448
  [&lt;0000014b7559894c&gt;] ksys_write+0x74/0x100
  [&lt;0000014b7618a440&gt;] __do_syscall+0x268/0x328
  [&lt;0000014b761a3558&gt;] system_call+0x70/0x98
  INFO: lockdep is turned off.
  Last Breaking-Event-Address:
  [&lt;0000014b75e7b636&gt;] ap_parse_bitmap_str+0x13e/0x1f8
  Kernel panic - not syncing: Fatal exception: panic_on_oops
occured when /sys/bus/ap/a[pq]mask was updated with a relative mask value
(like +0x10-0x12,+60,-90) with one of the numeric values exceeding INT_MAX.
The fix is simple: use unsigned long values for the internal variables. The
correct checks are already in place in the function but a simple int for
the internal variables was used with the possibility to overflow.
CVE-2024-38597:In the Linux kernel, the following vulnerability has been resolved:
eth: sungem: remove .ndo_poll_controller to avoid deadlocks
Erhard reports netpoll warnings from sungem:
  netpoll_send_skb_on_dev(): eth0 enabled interrupts in poll (gem_start_xmit+0x0/0x398)
  WARNING: CPU: 1 PID: 1 at net/core/netpoll.c:370 netpoll_send_skb+0x1fc/0x20c
gem_poll_controller() disables interrupts, which may sleep.
We can't sleep in netpoll, it has interrupts disabled completely.
Strangely, gem_poll_controller() doesn't even poll the completions,
and instead acts as if an interrupt has fired so it just schedules
NAPI and exits. None of this has been necessary for years, since
netpoll invokes NAPI directly.
CVE-2024-39292:In the Linux kernel, the following vulnerability has been resolved:
um: Add winch to winch_handlers before registering winch IRQ
Registering a winch IRQ is racy, an interrupt may occur before the winch is
added to the winch_handlers list.
If that happens, register_winch_irq() adds to that list a winch that is
scheduled to be (or has already been) freed, causing a panic later in
winch_cleanup().
Avoid the race by adding the winch to the winch_handlers list before
registering the IRQ, and rolling back if um_request_irq() fails.
CVE-2021-47618:In the Linux kernel, the following vulnerability has been resolved:
ARM: 9170/1: fix panic when kasan and kprobe are enabled
arm32 uses software to simulate the instruction replaced
by kprobe. some instructions may be simulated by constructing
assembly functions. therefore, before executing instruction
simulation, it is necessary to construct assembly function
execution environment in C language through binding registers.
after kasan is enabled, the register binding relationship will
be destroyed, resulting in instruction simulation errors and
causing kernel panic.
the kprobe emulate instruction function is distributed in three
files: actions-common.c actions-arm.c actions-thumb.c, so disable
KASAN when compiling these files.
for example, use kprobe insert on cap_capable+20 after kasan
enabled, the cap_capable assembly code is as follows:
&lt;cap_capable&gt;:
e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}
e1a05000	mov	r5, r0
e280006c	add	r0, r0, #108    ; 0x6c
e1a04001	mov	r4, r1
e1a06002	mov	r6, r2
e59fa090	ldr	sl, [pc, #144]  ;
ebfc7bf8	bl	c03aa4b4 &lt;__asan_load4&gt;
e595706c	ldr	r7, [r5, #108]  ; 0x6c
e2859014	add	r9, r5, #20
......
The emulate_ldr assembly code after enabling kasan is as follows:
c06f1384 &lt;emulate_ldr&gt;:
e92d47f0	push	{r4, r5, r6, r7, r8, r9, sl, lr}
e282803c	add	r8, r2, #60     ; 0x3c
e1a05000	mov	r5, r0
e7e37855	ubfx	r7, r5, #16, #4
e1a00008	mov	r0, r8
e1a09001	mov	r9, r1
e1a04002	mov	r4, r2
ebf35462	bl	c03c6530 &lt;__asan_load4&gt;
e357000f	cmp	r7, #15
e7e36655	ubfx	r6, r5, #12, #4
e205a00f	and	sl, r5, #15
0a000001	beq	c06f13bc &lt;emulate_ldr+0x38&gt;
e0840107	add	r0, r4, r7, lsl #2
ebf3545c	bl	c03c6530 &lt;__asan_load4&gt;
e084010a	add	r0, r4, sl, lsl #2
ebf3545a	bl	c03c6530 &lt;__asan_load4&gt;
e2890010	add	r0, r9, #16
ebf35458	bl	c03c6530 &lt;__asan_load4&gt;
e5990010	ldr	r0, [r9, #16]
e12fff30	blx	r0
e356000f	cm	r6, #15
1a000014	bne	c06f1430 &lt;emulate_ldr+0xac&gt;
e1a06000	mov	r6, r0
e2840040	add	r0, r4, #64     ; 0x40
......
when running in emulate_ldr to simulate the ldr instruction, panic
occurred, and the log is as follows:
Unable to handle kernel NULL pointer dereference at virtual address
00000090
pgd = ecb46400
[00000090] *pgd=2e0fa003, *pmd=00000000
Internal error: Oops: 206 [#1] SMP ARM
PC is at cap_capable+0x14/0xb0
LR is at emulate_ldr+0x50/0xc0
psr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30c
r10: 00000000  r9 : c30897f4  r8 : ecd63cd4
r7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98
r3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008
Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment user
Control: 32c5387d  Table: 2d546400  DAC: 55555555
Process bash (pid: 1643, stack limit = 0xecd60190)
(cap_capable) from (kprobe_handler+0x218/0x340)
(kprobe_handler) from (kprobe_trap_handler+0x24/0x48)
(kprobe_trap_handler) from (do_undefinstr+0x13c/0x364)
(do_undefinstr) from (__und_svc_finish+0x0/0x30)
(__und_svc_finish) from (cap_capable+0x18/0xb0)
(cap_capable) from (cap_vm_enough_memory+0x38/0x48)
(cap_vm_enough_memory) from
(security_vm_enough_memory_mm+0x48/0x6c)
(security_vm_enough_memory_mm) from
(copy_process.constprop.5+0x16b4/0x25c8)
(copy_process.constprop.5) from (_do_fork+0xe8/0x55c)
(_do_fork) from (SyS_clone+0x1c/0x24)
(SyS_clone) from (__sys_trace_return+0x0/0x10)
Code: 0050a0e1 6c0080e2 0140a0e1 0260a0e1 (f801f0e7)
CVE-2024-36014:In the Linux kernel, the following vulnerability has been resolved:
drm/arm/malidp: fix a possible null pointer dereference
In malidp_mw_connector_reset, new memory is allocated with kzalloc, but
no check is performed. In order to prevent null pointer dereferencing,
ensure that mw_state is checked before calling
__drm_atomic_helper_connector_reset.
CVE-2024-38590:In the Linux kernel, the following vulnerability has been resolved:
RDMA/hns: Modify the print level of CQE error
Too much print may lead to a panic in kernel. Change ibdev_err() to
ibdev_err_ratelimited(), and change the printing level of cqe dump
to debug level.
CVE-2024-38620:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: HCI: Remove HCI_AMP support
Since BT_HS has been remove HCI_AMP controllers no longer has any use so
remove it along with the capability of creating AMP controllers.
Since we no longer need to differentiate between AMP and Primary
controllers, as only HCI_PRIMARY is left, this also remove
hdev-&gt;dev_type altogether.
CVE-2022-48761:In the Linux kernel, the following vulnerability has been resolved:
usb: xhci-plat: fix crash when suspend if remote wake enable
Crashed at i.mx8qm platform when suspend if enable remote wakeup
Internal error: synchronous external abort: 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 2 PID: 244 Comm: kworker/u12:6 Not tainted 5.15.5-dirty #12
Hardware name: Freescale i.MX8QM MEK (DT)
Workqueue: events_unbound async_run_entry_fn
pstate: 600000c5 (nZCv daIF -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : xhci_disable_hub_port_wake.isra.62+0x60/0xf8
lr : xhci_disable_hub_port_wake.isra.62+0x34/0xf8
sp : ffff80001394bbf0
x29: ffff80001394bbf0 x28: 0000000000000000 x27: ffff00081193b578
x26: ffff00081193b570 x25: 0000000000000000 x24: 0000000000000000
x23: ffff00081193a29c x22: 0000000000020001 x21: 0000000000000001
x20: 0000000000000000 x19: ffff800014e90490 x18: 0000000000000000
x17: 0000000000000000 x16: 0000000000000000 x15: 0000000000000000
x14: 0000000000000000 x13: 0000000000000002 x12: 0000000000000000
x11: 0000000000000000 x10: 0000000000000960 x9 : ffff80001394baa0
x8 : ffff0008145d1780 x7 : ffff0008f95b8e80 x6 : 000000001853b453
x5 : 0000000000000496 x4 : 0000000000000000 x3 : ffff00081193a29c
x2 : 0000000000000001 x1 : 0000000000000000 x0 : ffff000814591620
Call trace:
 xhci_disable_hub_port_wake.isra.62+0x60/0xf8
 xhci_suspend+0x58/0x510
 xhci_plat_suspend+0x50/0x78
 platform_pm_suspend+0x2c/0x78
 dpm_run_callback.isra.25+0x50/0xe8
 __device_suspend+0x108/0x3c0
The basic flow:
	1. run time suspend call xhci_suspend, xhci parent devices gate the clock.
        2. echo mem &gt;/sys/power/state, system _device_suspend call xhci_suspend
        3. xhci_suspend call xhci_disable_hub_port_wake, which access register,
	   but clock already gated by run time suspend.
This problem was hidden by power domain driver, which call run time resume before it.
But the below commit remove it and make this issue happen.
	commit c1df456d0f06e (&quot;PM: domains: Don't runtime resume devices at genpd_prepare()&quot;)
This patch call run time resume before suspend to make sure clock is on
before access register.
Testeb-by: Abel Vesa &lt;abel.vesa@nxp.com&gt;
CVE-2024-39461:In the Linux kernel, the following vulnerability has been resolved:
clk: bcm: rpi: Assign -&gt;num before accessing -&gt;hws
Commit f316cdff8d67 (&quot;clk: Annotate struct clk_hw_onecell_data with
__counted_by&quot;) annotated the hws member of 'struct clk_hw_onecell_data'
with __counted_by, which informs the bounds sanitizer about the number
of elements in hws, so that it can warn when hws is accessed out of
bounds. As noted in that change, the __counted_by member must be
initialized with the number of elements before the first array access
happens, otherwise there will be a warning from each access prior to the
initialization because the number of elements is zero. This occurs in
raspberrypi_discover_clocks() due to -&gt;num being assigned after -&gt;hws
has been accessed:
  UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-raspberrypi.c:374:4
  index 3 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')
Move the -&gt;num initialization to before the first access of -&gt;hws, which
clears up the warning.
CVE-2021-47441:In the Linux kernel, the following vulnerability has been resolved:
mlxsw: thermal: Fix out-of-bounds memory accesses
Currently, mlxsw allows cooling states to be set above the maximum
cooling state supported by the driver:
 # cat /sys/class/thermal/thermal_zone2/cdev0/type
 mlxsw_fan
 # cat /sys/class/thermal/thermal_zone2/cdev0/max_state
 10
 # echo 18 &gt; /sys/class/thermal/thermal_zone2/cdev0/cur_state
 # echo $?
 0
This results in out-of-bounds memory accesses when thermal state
transition statistics are enabled (CONFIG_THERMAL_STATISTICS=y), as the
transition table is accessed with a too large index (state) [1].
According to the thermal maintainer, it is the responsibility of the
driver to reject such operations [2].
Therefore, return an error when the state to be set exceeds the maximum
cooling state supported by the driver.
To avoid dead code, as suggested by the thermal maintainer [3],
partially revert commit a421ce088ac8 (&quot;mlxsw: core: Extend cooling
device with cooling levels&quot;) that tried to interpret these invalid
cooling states (above the maximum) in a special way. The cooling levels
array is not removed in order to prevent the fans going below 20% PWM,
which would cause them to get stuck at 0% PWM.
[1]
BUG: KASAN: slab-out-of-bounds in thermal_cooling_device_stats_update+0x271/0x290
Read of size 4 at addr ffff8881052f7bf8 by task kworker/0:0/5
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.15.0-rc3-custom-45935-gce1adf704b14 #122
Hardware name: Mellanox Technologies Ltd. &quot;MSN2410-CB2FO&quot;/&quot;SA000874&quot;, BIOS 4.6.5 03/08/2016
Workqueue: events_freezable_power_ thermal_zone_device_check
Call Trace:
 dump_stack_lvl+0x8b/0xb3
 print_address_description.constprop.0+0x1f/0x140
 kasan_report.cold+0x7f/0x11b
 thermal_cooling_device_stats_update+0x271/0x290
 __thermal_cdev_update+0x15e/0x4e0
 thermal_cdev_update+0x9f/0xe0
 step_wise_throttle+0x770/0xee0
 thermal_zone_device_update+0x3f6/0xdf0
 process_one_work+0xa42/0x1770
 worker_thread+0x62f/0x13e0
 kthread+0x3ee/0x4e0
 ret_from_fork+0x1f/0x30
Allocated by task 1:
 kasan_save_stack+0x1b/0x40
 __kasan_kmalloc+0x7c/0x90
 thermal_cooling_device_setup_sysfs+0x153/0x2c0
 __thermal_cooling_device_register.part.0+0x25b/0x9c0
 thermal_cooling_device_register+0xb3/0x100
 mlxsw_thermal_init+0x5c5/0x7e0
 __mlxsw_core_bus_device_register+0xcb3/0x19c0
 mlxsw_core_bus_device_register+0x56/0xb0
 mlxsw_pci_probe+0x54f/0x710
 local_pci_probe+0xc6/0x170
 pci_device_probe+0x2b2/0x4d0
 really_probe+0x293/0xd10
 __driver_probe_device+0x2af/0x440
 driver_probe_device+0x51/0x1e0
 __driver_attach+0x21b/0x530
 bus_for_each_dev+0x14c/0x1d0
 bus_add_driver+0x3ac/0x650
 driver_register+0x241/0x3d0
 mlxsw_sp_module_init+0xa2/0x174
 do_one_initcall+0xee/0x5f0
 kernel_init_freeable+0x45a/0x4de
 kernel_init+0x1f/0x210
 ret_from_fork+0x1f/0x30
The buggy address belongs to the object at ffff8881052f7800
 which belongs to the cache kmalloc-1k of size 1024
The buggy address is located 1016 bytes inside of
 1024-byte region [ffff8881052f7800, ffff8881052f7c00)
The buggy address belongs to the page:
page:0000000052355272 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1052f0
head:0000000052355272 order:3 compound_mapcount:0 compound_pincount:0
flags: 0x200000000010200(slab|head|node=0|zone=2)
raw: 0200000000010200 ffffea0005034800 0000000300000003 ffff888100041dc0
raw: 0000000000000000 0000000000100010 00000001ffffffff 0000000000000000
page dumped because: kasan: bad access detected
Memory state around the buggy address:
 ffff8881052f7a80: 00 00 00 00 00 00 04 fc fc fc fc fc fc fc fc fc
 ffff8881052f7b00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
&gt;ffff8881052f7b80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
                                                                ^
 ffff8881052f7c00: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
 ffff8881052f7c80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[2] https://lore.kernel.org/linux-pm/9aca37cb-1629-5c67-
---truncated---
CVE-2024-39462:In the Linux kernel, the following vulnerability has been resolved:
clk: bcm: dvp: Assign -&gt;num before accessing -&gt;hws
Commit f316cdff8d67 (&quot;clk: Annotate struct clk_hw_onecell_data with
__counted_by&quot;) annotated the hws member of 'struct clk_hw_onecell_data'
with __counted_by, which informs the bounds sanitizer about the number
of elements in hws, so that it can warn when hws is accessed out of
bounds. As noted in that change, the __counted_by member must be
initialized with the number of elements before the first array access
happens, otherwise there will be a warning from each access prior to the
initialization because the number of elements is zero. This occurs in
clk_dvp_probe() due to -&gt;num being assigned after -&gt;hws has been
accessed:
  UBSAN: array-index-out-of-bounds in drivers/clk/bcm/clk-bcm2711-dvp.c:59:2
  index 0 is out of range for type 'struct clk_hw *[] __counted_by(num)' (aka 'struct clk_hw *[]')
Move the -&gt;num initialization to before the first access of -&gt;hws, which
clears up the warning.
CVE-2022-48720:In the Linux kernel, the following vulnerability has been resolved:
net: macsec: Fix offload support for NETDEV_UNREGISTER event
Current macsec netdev notify handler handles NETDEV_UNREGISTER event by
releasing relevant SW resources only, this causes resources leak in case
of macsec HW offload, as the underlay driver was not notified to clean
it's macsec offload resources.
Fix by calling the underlay driver to clean it's relevant resources
by moving offload handling from macsec_dellink() to macsec_common_dellink()
when handling NETDEV_UNREGISTER event.
CVE-2023-52884:In the Linux kernel, the following vulnerability has been resolved:
Input: cyapa - add missing input core locking to suspend/resume functions
Grab input-&gt;mutex during suspend/resume functions like it is done in
other input drivers. This fixes the following warning during system
suspend/resume cycle on Samsung Exynos5250-based Snow Chromebook:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c
Modules linked in: ...
CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G        W          6.6.0-rc5-next-20231009 #14109
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events_unbound async_run_entry_fn
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x58/0x70
 dump_stack_lvl from __warn+0x1a8/0x1cc
 __warn from warn_slowpath_fmt+0x18c/0x1b4
 warn_slowpath_fmt from input_device_enabled+0x68/0x6c
 input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc
 cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c
 cyapa_reinitialize from cyapa_resume+0x48/0x98
 cyapa_resume from dpm_run_callback+0x90/0x298
 dpm_run_callback from device_resume+0xb4/0x258
 device_resume from async_resume+0x20/0x64
 async_resume from async_run_entry_fn+0x40/0x15c
 async_run_entry_fn from process_scheduled_works+0xbc/0x6a8
 process_scheduled_works from worker_thread+0x188/0x454
 worker_thread from kthread+0x108/0x140
 kthread from ret_from_fork+0x14/0x28
Exception stack(0xf1625fb0 to 0xf1625ff8)
...
---[ end trace 0000000000000000 ]---
...
------------[ cut here ]------------
WARNING: CPU: 1 PID: 1680 at drivers/input/input.c:2291 input_device_enabled+0x68/0x6c
Modules linked in: ...
CPU: 1 PID: 1680 Comm: kworker/u4:12 Tainted: G        W          6.6.0-rc5-next-20231009 #14109
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events_unbound async_run_entry_fn
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x58/0x70
 dump_stack_lvl from __warn+0x1a8/0x1cc
 __warn from warn_slowpath_fmt+0x18c/0x1b4
 warn_slowpath_fmt from input_device_enabled+0x68/0x6c
 input_device_enabled from cyapa_gen3_set_power_mode+0x13c/0x1dc
 cyapa_gen3_set_power_mode from cyapa_reinitialize+0x10c/0x15c
 cyapa_reinitialize from cyapa_resume+0x48/0x98
 cyapa_resume from dpm_run_callback+0x90/0x298
 dpm_run_callback from device_resume+0xb4/0x258
 device_resume from async_resume+0x20/0x64
 async_resume from async_run_entry_fn+0x40/0x15c
 async_run_entry_fn from process_scheduled_works+0xbc/0x6a8
 process_scheduled_works from worker_thread+0x188/0x454
 worker_thread from kthread+0x108/0x140
 kthread from ret_from_fork+0x14/0x28
Exception stack(0xf1625fb0 to 0xf1625ff8)
...
---[ end trace 0000000000000000 ]---
CVE-2022-48748:In the Linux kernel, the following vulnerability has been resolved:
net: bridge: vlan: fix memory leak in __allowed_ingress
When using per-vlan state, if vlan snooping and stats are disabled,
untagged or priority-tagged ingress frame will go to check pvid state.
If the port state is forwarding and the pvid state is not
learning/forwarding, untagged or priority-tagged frame will be dropped
but skb memory is not freed.
Should free skb when __allowed_ingress returns false.
CVE-2024-36481:In the Linux kernel, the following vulnerability has been resolved:
tracing/probes: fix error check in parse_btf_field()
btf_find_struct_member() might return NULL or an error via the
ERR_PTR() macro. However, its caller in parse_btf_field() only checks
for the NULL condition. Fix this by using IS_ERR() and returning the
error up the stack.
CVE-2024-38384:In the Linux kernel, the following vulnerability has been resolved:
blk-cgroup: fix list corruption from reorder of WRITE -&gt;lqueued
__blkcg_rstat_flush() can be run anytime, especially when blk_cgroup_bio_start
is being executed.
If WRITE of `-&gt;lqueued` is re-ordered with READ of 'bisc-&gt;lnode.next' in
the loop of __blkcg_rstat_flush(), `next_bisc` can be assigned with one
stat instance being added in blk_cgroup_bio_start(), then the local
list in __blkcg_rstat_flush() could be corrupted.
Fix the issue by adding one barrier.
CVE-2024-39470:In the Linux kernel, the following vulnerability has been resolved:
eventfs: Fix a possible null pointer dereference in eventfs_find_events()
In function eventfs_find_events,there is a potential null pointer
that may be caused by calling update_events_attr which will perform
some operations on the members of the ei struct when ei is NULL.
Hence,When ei-&gt;is_freed is set,return NULL directly.
CVE-2024-39465:In the Linux kernel, the following vulnerability has been resolved:
media: mgb4: Fix double debugfs remove
Fixes an error where debugfs_remove_recursive() is called first on a parent
directory and then again on a child which causes a kernel panic.
[hverkuil: added Fixes/Cc tags]
CVE-2024-39466:In the Linux kernel, the following vulnerability has been resolved:
thermal/drivers/qcom/lmh: Check for SCM availability at probe
Up until now, the necessary scm availability check has not been
performed, leading to possible null pointer dereferences (which did
happen for me on RB1).
Fix that.
CVE-2024-35785:In the Linux kernel, the following vulnerability has been resolved:
tee: optee: Fix kernel panic caused by incorrect error handling
The error path while failing to register devices on the TEE bus has a
bug leading to kernel panic as follows:
[   15.398930] Unable to handle kernel paging request at virtual address ffff07ed00626d7c
[   15.406913] Mem abort info:
[   15.409722]   ESR = 0x0000000096000005
[   15.413490]   EC = 0x25: DABT (current EL), IL = 32 bits
[   15.418814]   SET = 0, FnV = 0
[   15.421878]   EA = 0, S1PTW = 0
[   15.425031]   FSC = 0x05: level 1 translation fault
[   15.429922] Data abort info:
[   15.432813]   ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000
[   15.438310]   CM = 0, WnR = 0, TnD = 0, TagAccess = 0
[   15.443372]   GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0
[   15.448697] swapper pgtable: 4k pages, 48-bit VAs, pgdp=00000000d9e3e000
[   15.455413] [ffff07ed00626d7c] pgd=1800000bffdf9003, p4d=1800000bffdf9003, pud=0000000000000000
[   15.464146] Internal error: Oops: 0000000096000005 [#1] PREEMPT SMP
Commit 7269cba53d90 (&quot;tee: optee: Fix supplicant based device enumeration&quot;)
lead to the introduction of this bug. So fix it appropriately.
CVE-2024-35949:In the Linux kernel, the following vulnerability has been resolved:
btrfs: make sure that WRITTEN is set on all metadata blocks
We previously would call btrfs_check_leaf() if we had the check
integrity code enabled, which meant that we could only run the extended
leaf checks if we had WRITTEN set on the header flags.
This leaves a gap in our checking, because we could end up with
corruption on disk where WRITTEN isn't set on the leaf, and then the
extended leaf checks don't get run which we rely on to validate all of
the item pointers to make sure we don't access memory outside of the
extent buffer.
However, since 732fab95abe2 (&quot;btrfs: check-integrity: remove
CONFIG_BTRFS_FS_CHECK_INTEGRITY option&quot;) we no longer call
btrfs_check_leaf() from btrfs_mark_buffer_dirty(), which means we only
ever call it on blocks that are being written out, and thus have WRITTEN
set, or that are being read in, which should have WRITTEN set.
Add checks to make sure we have WRITTEN set appropriately, and then make
sure __btrfs_check_leaf() always does the item checking.  This will
protect us from file systems that have been corrupted and no longer have
WRITTEN set on some of the blocks.
This was hit on a crafted image tweaking the WRITTEN bit and reported by
KASAN as out-of-bound access in the eb accessors. The example is a dir
item at the end of an eb.
  [2.042] BTRFS warning (device loop1): bad eb member start: ptr 0x3fff start 30572544 member offset 16410 size 2
  [2.040] general protection fault, probably for non-canonical address 0xe0009d1000000003: 0000 [#1] PREEMPT SMP KASAN NOPTI
  [2.537] KASAN: maybe wild-memory-access in range [0x0005088000000018-0x000508800000001f]
  [2.729] CPU: 0 PID: 2587 Comm: mount Not tainted 6.8.2 #1
  [2.729] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
  [2.621] RIP: 0010:btrfs_get_16+0x34b/0x6d0
  [2.621] RSP: 0018:ffff88810871fab8 EFLAGS: 00000206
  [2.621] RAX: 0000a11000000003 RBX: ffff888104ff8720 RCX: ffff88811b2288c0
  [2.621] RDX: dffffc0000000000 RSI: ffffffff81dd8aca RDI: ffff88810871f748
  [2.621] RBP: 000000000000401a R08: 0000000000000001 R09: ffffed10210e3ee9
  [2.621] R10: ffff88810871f74f R11: 205d323430333737 R12: 000000000000001a
  [2.621] R13: 000508800000001a R14: 1ffff110210e3f5d R15: ffffffff850011e8
  [2.621] FS:  00007f56ea275840(0000) GS:ffff88811b200000(0000) knlGS:0000000000000000
  [2.621] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [2.621] CR2: 00007febd13b75c0 CR3: 000000010bb50000 CR4: 00000000000006f0
  [2.621] Call Trace:
  [2.621]  &lt;TASK&gt;
  [2.621]  ? show_regs+0x74/0x80
  [2.621]  ? die_addr+0x46/0xc0
  [2.621]  ? exc_general_protection+0x161/0x2a0
  [2.621]  ? asm_exc_general_protection+0x26/0x30
  [2.621]  ? btrfs_get_16+0x33a/0x6d0
  [2.621]  ? btrfs_get_16+0x34b/0x6d0
  [2.621]  ? btrfs_get_16+0x33a/0x6d0
  [2.621]  ? __pfx_btrfs_get_16+0x10/0x10
  [2.621]  ? __pfx_mutex_unlock+0x10/0x10
  [2.621]  btrfs_match_dir_item_name+0x101/0x1a0
  [2.621]  btrfs_lookup_dir_item+0x1f3/0x280
  [2.621]  ? __pfx_btrfs_lookup_dir_item+0x10/0x10
  [2.621]  btrfs_get_tree+0xd25/0x1910
[ copy more details from report ]
CVE-2024-36931:In the Linux kernel, the following vulnerability has been resolved:
s390/cio: Ensure the copied buf is NUL terminated
Currently, we allocate a lbuf-sized kernel buffer and copy lbuf from
userspace to that buffer. Later, we use scanf on this buffer but we don't
ensure that the string is terminated inside the buffer, this can lead to
OOB read when using scanf. Fix this issue by using memdup_user_nul instead.
CVE-2024-36937:In the Linux kernel, the following vulnerability has been resolved:
xdp: use flags field to disambiguate broadcast redirect
When redirecting a packet using XDP, the bpf_redirect_map() helper will set
up the redirect destination information in struct bpf_redirect_info (using
the __bpf_xdp_redirect_map() helper function), and the xdp_do_redirect()
function will read this information after the XDP program returns and pass
the frame on to the right redirect destination.
When using the BPF_F_BROADCAST flag to do multicast redirect to a whole
map, __bpf_xdp_redirect_map() sets the 'map' pointer in struct
bpf_redirect_info to point to the destination map to be broadcast. And
xdp_do_redirect() reacts to the value of this map pointer to decide whether
it's dealing with a broadcast or a single-value redirect. However, if the
destination map is being destroyed before xdp_do_redirect() is called, the
map pointer will be cleared out (by bpf_clear_redirect_map()) without
waiting for any XDP programs to stop running. This causes xdp_do_redirect()
to think that the redirect was to a single target, but the target pointer
is also NULL (since broadcast redirects don't have a single target), so
this causes a crash when a NULL pointer is passed to dev_map_enqueue().
To fix this, change xdp_do_redirect() to react directly to the presence of
the BPF_F_BROADCAST flag in the 'flags' value in struct bpf_redirect_info
to disambiguate between a single-target and a broadcast redirect. And only
read the 'map' pointer if the broadcast flag is set, aborting if that has
been cleared out in the meantime. This prevents the crash, while keeping
the atomic (cmpxchg-based) clearing of the map pointer itself, and without
adding any more checks in the non-broadcast fast path.
CVE-2024-36028:In the Linux kernel, the following vulnerability has been resolved:
mm/hugetlb: fix DEBUG_LOCKS_WARN_ON(1) when dissolve_free_hugetlb_folio()
When I did memory failure tests recently, below warning occurs:
DEBUG_LOCKS_WARN_ON(1)
WARNING: CPU: 8 PID: 1011 at kernel/locking/lockdep.c:232 __lock_acquire+0xccb/0x1ca0
Modules linked in: mce_inject hwpoison_inject
CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
RIP: 0010:__lock_acquire+0xccb/0x1ca0
RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082
RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0
RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb
R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10
R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004
FS:  00007ff9f32aa740(0000) GS:ffffa1ce5fc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff9f3134ba0 CR3: 00000008484e4000 CR4: 00000000000006f0
Call Trace:
 &lt;TASK&gt;
 lock_acquire+0xbe/0x2d0
 _raw_spin_lock_irqsave+0x3a/0x60
 hugepage_subpool_put_pages.part.0+0xe/0xc0
 free_huge_folio+0x253/0x3f0
 dissolve_free_huge_page+0x147/0x210
 __page_handle_poison+0x9/0x70
 memory_failure+0x4e6/0x8c0
 hard_offline_page_store+0x55/0xa0
 kernfs_fop_write_iter+0x12c/0x1d0
 vfs_write+0x380/0x540
 ksys_write+0x64/0xe0
 do_syscall_64+0xbc/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff9f3114887
RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887
RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001
RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00
 &lt;/TASK&gt;
Kernel panic - not syncing: kernel: panic_on_warn set ...
CPU: 8 PID: 1011 Comm: bash Kdump: loaded Not tainted 6.9.0-rc3-next-20240410-00012-gdb69f219f4be #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.14.0-0-g155821a1990b-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 panic+0x326/0x350
 check_panic_on_warn+0x4f/0x50
 __warn+0x98/0x190
 report_bug+0x18e/0x1a0
 handle_bug+0x3d/0x70
 exc_invalid_op+0x18/0x70
 asm_exc_invalid_op+0x1a/0x20
RIP: 0010:__lock_acquire+0xccb/0x1ca0
RSP: 0018:ffffa7a1c7fe3bd0 EFLAGS: 00000082
RAX: 0000000000000000 RBX: eb851eb853975fcf RCX: ffffa1ce5fc1c9c8
RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffffa1ce5fc1c9c0
RBP: ffffa1c6865d3280 R08: ffffffffb0f570a8 R09: 0000000000009ffb
R10: 0000000000000286 R11: ffffffffb0f2ad50 R12: ffffa1c6865d3d10
R13: ffffa1c6865d3c70 R14: 0000000000000000 R15: 0000000000000004
 lock_acquire+0xbe/0x2d0
 _raw_spin_lock_irqsave+0x3a/0x60
 hugepage_subpool_put_pages.part.0+0xe/0xc0
 free_huge_folio+0x253/0x3f0
 dissolve_free_huge_page+0x147/0x210
 __page_handle_poison+0x9/0x70
 memory_failure+0x4e6/0x8c0
 hard_offline_page_store+0x55/0xa0
 kernfs_fop_write_iter+0x12c/0x1d0
 vfs_write+0x380/0x540
 ksys_write+0x64/0xe0
 do_syscall_64+0xbc/0x1d0
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7ff9f3114887
RSP: 002b:00007ffecbacb458 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 000000000000000c RCX: 00007ff9f3114887
RDX: 000000000000000c RSI: 0000564494164e10 RDI: 0000000000000001
RBP: 0000564494164e10 R08: 00007ff9f31d1460 R09: 000000007fffffff
R10: 0000000000000000 R11: 0000000000000246 R12: 000000000000000c
R13: 00007ff9f321b780 R14: 00007ff9f3217600 R15: 00007ff9f3216a00
 &lt;/TASK&gt;
After git bisecting and digging into the code, I believe the root cause is
that _deferred_list field of folio is unioned with _hugetlb_subpool field.
In __update_and_free_hugetlb_folio(), folio-&gt;_deferred_
---truncated---
CVE-2024-27405:In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: ncm: Avoid dropping datagrams of properly parsed NTBs
It is observed sometimes when tethering is used over NCM with Windows 11
as host, at some instances, the gadget_giveback has one byte appended at
the end of a proper NTB. When the NTB is parsed, unwrap call looks for
any leftover bytes in SKB provided by u_ether and if there are any pending
bytes, it treats them as a separate NTB and parses it. But in case the
second NTB (as per unwrap call) is faulty/corrupt, all the datagrams that
were parsed properly in the first NTB and saved in rx_list are dropped.
Adding a few custom traces showed the following:
[002] d..1  7828.532866: dwc3_gadget_giveback: ep1out:
req 000000003868811a length 1025/16384 zsI ==&gt; 0
[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb toprocess: 1025
[002] d..1  7828.532867: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb seq: 0xce67
[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x400
[002] d..1  7828.532868: ncm_unwrap_ntb: K: ncm_unwrap_ntb ndp_len: 0x10
[002] d..1  7828.532869: ncm_unwrap_ntb: K: Parsed NTB with 1 frames
In this case, the giveback is of 1025 bytes and block length is 1024.
The rest 1 byte (which is 0x00) won't be parsed resulting in drop of
all datagrams in rx_list.
Same is case with packets of size 2048:
[002] d..1  7828.557948: dwc3_gadget_giveback: ep1out:
req 0000000011dfd96e length 2049/16384 zsI ==&gt; 0
[002] d..1  7828.557949: ncm_unwrap_ntb: K: ncm_unwrap_ntb nth: 1751999342
[002] d..1  7828.557950: ncm_unwrap_ntb: K: ncm_unwrap_ntb blk_len: 0x800
Lecroy shows one byte coming in extra confirming that the byte is coming
in from PC:
 Transfer 2959 - Bytes Transferred(1025)  Timestamp((18.524 843 590)
 - Transaction 8391 - Data(1025 bytes) Timestamp(18.524 843 590)
 --- Packet 4063861
       Data(1024 bytes)
       Duration(2.117us) Idle(14.700ns) Timestamp(18.524 843 590)
 --- Packet 4063863
       Data(1 byte)
       Duration(66.160ns) Time(282.000ns) Timestamp(18.524 845 722)
According to Windows driver, no ZLP is needed if wBlockLength is non-zero,
because the non-zero wBlockLength has already told the function side the
size of transfer to be expected. However, there are in-market NCM devices
that rely on ZLP as long as the wBlockLength is multiple of wMaxPacketSize.
To deal with such devices, it pads an extra 0 at end so the transfer is no
longer multiple of wMaxPacketSize.
CVE-2021-47568:In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix memleak in get_file_stream_info()
Fix memleak in get_file_stream_info()
CVE-2024-39492:In the Linux kernel, the following vulnerability has been resolved:
mailbox: mtk-cmdq: Fix pm_runtime_get_sync() warning in mbox shutdown
The return value of pm_runtime_get_sync() in cmdq_mbox_shutdown()
will return 1 when pm runtime state is active, and we don't want to
get the warning message in this case.
So we change the return value &lt; 0 for WARN_ON().
CVE-2021-47598:In the Linux kernel, the following vulnerability has been resolved:
sch_cake: do not call cake_destroy() from cake_init()
qdiscs are not supposed to call their own destroy() method
from init(), because core stack already does that.
syzbot was able to trigger use after free:
DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock_common kernel/locking/mutex.c:586 [inline]
WARNING: CPU: 0 PID: 21902 at kernel/locking/mutex.c:586 __mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740
Modules linked in:
CPU: 0 PID: 21902 Comm: syz-executor189 Not tainted 5.16.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
RIP: 0010:__mutex_lock_common kernel/locking/mutex.c:586 [inline]
RIP: 0010:__mutex_lock+0x9ec/0x12f0 kernel/locking/mutex.c:740
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
RSP: 0018:ffffc9000627f290 EFLAGS: 00010282
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000000
RDX: ffff88802315d700 RSI: ffffffff815f1db8 RDI: fffff52000c4fe44
RBP: ffff88818f28e000 R08: 0000000000000000 R09: 0000000000000000
R10: ffffffff815ebb5e R11: 0000000000000000 R12: 0000000000000000
R13: dffffc0000000000 R14: ffffc9000627f458 R15: 0000000093c30000
FS:  0000555556abc400(0000) GS:ffff8880b9c00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fda689c3303 CR3: 000000001cfbb000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
 tcf_chain0_head_change_cb_del+0x2e/0x3d0 net/sched/cls_api.c:810
 tcf_block_put_ext net/sched/cls_api.c:1381 [inline]
 tcf_block_put_ext net/sched/cls_api.c:1376 [inline]
 tcf_block_put+0xbc/0x130 net/sched/cls_api.c:1394
 cake_destroy+0x3f/0x80 net/sched/sch_cake.c:2695
 qdisc_create.constprop.0+0x9da/0x10f0 net/sched/sch_api.c:1293
 tc_modify_qdisc+0x4c5/0x1980 net/sched/sch_api.c:1660
 rtnetlink_rcv_msg+0x413/0xb80 net/core/rtnetlink.c:5571
 netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2496
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x533/0x7d0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x904/0xdf0 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:704 [inline]
 sock_sendmsg+0xcf/0x120 net/socket.c:724
 ____sys_sendmsg+0x6e8/0x810 net/socket.c:2409
 ___sys_sendmsg+0xf3/0x170 net/socket.c:2463
 __sys_sendmsg+0xe5/0x1b0 net/socket.c:2492
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x44/0xae
RIP: 0033:0x7f1bb06badb9
Code: Unable to access opcode bytes at RIP 0x7f1bb06bad8f.
RSP: 002b:00007fff3012a658 EFLAGS: 00000246 ORIG_RAX: 000000000000002e
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f1bb06badb9
RDX: 0000000000000000 RSI: 00000000200007c0 RDI: 0000000000000003
RBP: 0000000000000000 R08: 0000000000000003 R09: 0000000000000003
R10: 0000000000000003 R11: 0000000000000246 R12: 00007fff3012a688
R13: 00007fff3012a6a0 R14: 00007fff3012a6e0 R15: 00000000000013c2
 &lt;/TASK&gt;
CVE-2024-36965:In the Linux kernel, the following vulnerability has been resolved:
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
The IPI buffer location is read from the firmware that we load to the
System Companion Processor, and it's not granted that both the SRAM
(L2TCM) size that is defined in the devicetree node is large enough
for that, and while this is especially true for multi-core SCP, it's
still useful to check on single-core variants as well.
Failing to perform this check may make this driver perform R/W
operations out of the L2TCM boundary, resulting (at best) in a
kernel panic.
To fix that, check that the IPI buffer fits, otherwise return a
failure and refuse to boot the relevant SCP core (or the SCP at
all, if this is single core).
CVE-2021-47187:In the Linux kernel, the following vulnerability has been resolved:
arm64: dts: qcom: msm8998: Fix CPU/L2 idle state latency and residency
The entry/exit latency and minimum residency in state for the idle
states of MSM8998 were ..bad: first of all, for all of them the
timings were written for CPU sleep but the min-residency-us param
was miscalculated (supposedly, while porting this from downstream);
Then, the power collapse states are setting PC on both the CPU
cluster *and* the L2 cache, which have different timings: in the
specific case of L2 the times are higher so these ones should be
taken into account instead of the CPU ones.
This parameter misconfiguration was not giving particular issues
because on MSM8998 there was no CPU scaling at all, so cluster/L2
power collapse was rarely (if ever) hit.
When CPU scaling is enabled, though, the wrong timings will produce
SoC unstability shown to the user as random, apparently error-less,
sudden reboots and/or lockups.
This set of parameters are stabilizing the SoC when CPU scaling is
ON and when power collapse is frequently hit.
CVE-2023-52657:In the Linux kernel, the following vulnerability has been resolved:
Revert &quot;drm/amd/pm: resolve reboot exception for si oland&quot;
This reverts commit e490d60a2f76bff636c68ce4fe34c1b6c34bbd86.
This causes hangs on SI when DC is enabled and errors on driver
reboot and power off cycles.
CVE-2024-35786:In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix stale locked mutex in nouveau_gem_ioctl_pushbuf
If VM_BIND is enabled on the client the legacy submission ioctl can't be
used, however if a client tries to do so regardless it will return an
error. In this case the clients mutex remained unlocked leading to a
deadlock inside nouveau_drm_postclose or any other nouveau ioctl call.
CVE-2024-27432:In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: mtk_eth_soc: fix PPE hanging issue
A patch to resolve an issue was found in MediaTek's GPL-licensed SDK:
In the mtk_ppe_stop() function, the PPE scan mode is not disabled before
disabling the PPE. This can potentially lead to a hang during the process
of disabling the PPE.
Without this patch, the PPE may experience a hang during the reboot test.
CVE-2023-52684:In the Linux kernel, the following vulnerability has been resolved:
firmware: qcom: qseecom: fix memory leaks in error paths
Fix instances of returning error codes directly instead of jumping to
the relevant labels where memory allocated for the SCM calls would be
freed.
CVE-2024-35850:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: fix NULL-deref on non-serdev setup
Qualcomm ROME controllers can be registered from the Bluetooth line
discipline and in this case the HCI UART serdev pointer is NULL.
Add the missing sanity check to prevent a NULL-pointer dereference when
setup() is called for a non-serdev controller.
CVE-2023-52689:In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add missing mutex lock around get meter levels
As scarlett2_meter_ctl_get() uses meter_level_map[], the data_mutex
should be locked while accessing it.
CVE-2023-52673:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix a debugfs null pointer error
[WHY &amp; HOW]
Check whether get_subvp_en() callback exists before calling it.
CVE-2023-52692:In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add missing error check to scarlett2_usb_set_config()
scarlett2_usb_set_config() calls scarlett2_usb_get() but was not
checking the result. Return the error if it fails rather than
continuing with an invalid value.
CVE-2021-47349:In the Linux kernel, the following vulnerability has been resolved:
mwifiex: bring down link before deleting interface
We can deadlock when rmmod'ing the driver or going through firmware
reset, because the cfg80211_unregister_wdev() has to bring down the link
for us, ... which then grab the same wiphy lock.
nl80211_del_interface() already handles a very similar case, with a nice
description:
        /*
         * We hold RTNL, so this is safe, without RTNL opencount cannot
         * reach 0, and thus the rdev cannot be deleted.
         *
         * We need to do it for the dev_close(), since that will call
         * the netdev notifiers, and we need to acquire the mutex there
         * but don't know if we get there from here or from some other
         * place (e.g. &quot;ip link set ... down&quot;).
         */
        mutex_unlock(&amp;rdev-&gt;wiphy.mtx);
...
Do similarly for mwifiex teardown, by ensuring we bring the link down
first.
Sample deadlock trace:
[  247.103516] INFO: task rmmod:2119 blocked for more than 123 seconds.
[  247.110630]       Not tainted 5.12.4 #5
[  247.115796] &quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
[  247.124557] task:rmmod           state:D stack:    0 pid: 2119 ppid:  2114 flags:0x00400208
[  247.133905] Call trace:
[  247.136644]  __switch_to+0x130/0x170
[  247.140643]  __schedule+0x714/0xa0c
[  247.144548]  schedule_preempt_disabled+0x88/0xf4
[  247.149714]  __mutex_lock_common+0x43c/0x750
[  247.154496]  mutex_lock_nested+0x5c/0x68
[  247.158884]  cfg80211_netdev_notifier_call+0x280/0x4e0 [cfg80211]
[  247.165769]  raw_notifier_call_chain+0x4c/0x78
[  247.170742]  call_netdevice_notifiers_info+0x68/0xa4
[  247.176305]  __dev_close_many+0x7c/0x138
[  247.180693]  dev_close_many+0x7c/0x10c
[  247.184893]  unregister_netdevice_many+0xfc/0x654
[  247.190158]  unregister_netdevice_queue+0xb4/0xe0
[  247.195424]  _cfg80211_unregister_wdev+0xa4/0x204 [cfg80211]
[  247.201816]  cfg80211_unregister_wdev+0x20/0x2c [cfg80211]
[  247.208016]  mwifiex_del_virtual_intf+0xc8/0x188 [mwifiex]
[  247.214174]  mwifiex_uninit_sw+0x158/0x1b0 [mwifiex]
[  247.219747]  mwifiex_remove_card+0x38/0xa0 [mwifiex]
[  247.225316]  mwifiex_pcie_remove+0xd0/0xe0 [mwifiex_pcie]
[  247.231451]  pci_device_remove+0x50/0xe0
[  247.235849]  device_release_driver_internal+0x110/0x1b0
[  247.241701]  driver_detach+0x5c/0x9c
[  247.245704]  bus_remove_driver+0x84/0xb8
[  247.250095]  driver_unregister+0x3c/0x60
[  247.254486]  pci_unregister_driver+0x2c/0x90
[  247.259267]  cleanup_module+0x18/0xcdc [mwifiex_pcie]
CVE-2021-47230:In the Linux kernel, the following vulnerability has been resolved:
KVM: x86: Immediately reset the MMU context when the SMM flag is cleared
Immediately reset the MMU context when the vCPU's SMM flag is cleared so
that the SMM flag in the MMU role is always synchronized with the vCPU's
flag.  If RSM fails (which isn't correctly emulated), KVM will bail
without calling post_leave_smm() and leave the MMU in a bad state.
The bad MMU role can lead to a NULL pointer dereference when grabbing a
shadow page's rmap for a page fault as the initial lookups for the gfn
will happen with the vCPU's SMM flag (=0), whereas the rmap lookup will
use the shadow page's SMM flag, which comes from the MMU (=1).  SMM has
an entirely different set of memslots, and so the initial lookup can find
a memslot (SMM=0) and then explode on the rmap memslot lookup (SMM=1).
  general protection fault, probably for non-canonical address 0xdffffc0000000000: 0000 [#1] PREEMPT SMP KASAN
  KASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]
  CPU: 1 PID: 8410 Comm: syz-executor382 Not tainted 5.13.0-rc5-syzkaller #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
  RIP: 0010:__gfn_to_rmap arch/x86/kvm/mmu/mmu.c:935 [inline]
  RIP: 0010:gfn_to_rmap+0x2b0/0x4d0 arch/x86/kvm/mmu/mmu.c:947
  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
  RSP: 0018:ffffc90000ffef98 EFLAGS: 00010246
  RAX: 0000000000000000 RBX: ffff888015b9f414 RCX: ffff888019669c40
  RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000001
  RBP: 0000000000000001 R08: ffffffff811d9cdb R09: ffffed10065a6002
  R10: ffffed10065a6002 R11: 0000000000000000 R12: dffffc0000000000
  R13: 0000000000000003 R14: 0000000000000001 R15: 0000000000000000
  FS:  000000000124b300(0000) GS:ffff8880b9b00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 0000000000000000 CR3: 0000000028e31000 CR4: 00000000001526e0
  DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
  DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
  Call Trace:
   rmap_add arch/x86/kvm/mmu/mmu.c:965 [inline]
   mmu_set_spte+0x862/0xe60 arch/x86/kvm/mmu/mmu.c:2604
   __direct_map arch/x86/kvm/mmu/mmu.c:2862 [inline]
   direct_page_fault+0x1f74/0x2b70 arch/x86/kvm/mmu/mmu.c:3769
   kvm_mmu_do_page_fault arch/x86/kvm/mmu.h:124 [inline]
   kvm_mmu_page_fault+0x199/0x1440 arch/x86/kvm/mmu/mmu.c:5065
   vmx_handle_exit+0x26/0x160 arch/x86/kvm/vmx/vmx.c:6122
   vcpu_enter_guest+0x3bdd/0x9630 arch/x86/kvm/x86.c:9428
   vcpu_run+0x416/0xc20 arch/x86/kvm/x86.c:9494
   kvm_arch_vcpu_ioctl_run+0x4e8/0xa40 arch/x86/kvm/x86.c:9722
   kvm_vcpu_ioctl+0x70f/0xbb0 arch/x86/kvm/../../../virt/kvm/kvm_main.c:3460
   vfs_ioctl fs/ioctl.c:51 [inline]
   __do_sys_ioctl fs/ioctl.c:1069 [inline]
   __se_sys_ioctl+0xfb/0x170 fs/ioctl.c:1055
   do_syscall_64+0x3f/0xb0 arch/x86/entry/common.c:47
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  RIP: 0033:0x440ce9
CVE-2024-35857:In the Linux kernel, the following vulnerability has been resolved:
icmp: prevent possible NULL dereferences from icmp_build_probe()
First problem is a double call to __in_dev_get_rcu(), because
the second one could return NULL.
if (__in_dev_get_rcu(dev) &amp;&amp; __in_dev_get_rcu(dev)-&gt;ifa_list)
Second problem is a read from dev-&gt;ip6_ptr with no NULL check:
if (!list_empty(&amp;rcu_dereference(dev-&gt;ip6_ptr)-&gt;addr_list))
Use the correct RCU API to fix these.
v2: add missing include &lt;net/addrconf.h&gt;
CVE-2021-47311:In the Linux kernel, the following vulnerability has been resolved:
net: qcom/emac: fix UAF in emac_remove
adpt is netdev private data and it cannot be
used after free_netdev() call. Using adpt after free_netdev()
can cause UAF bug. Fix it by moving free_netdev() at the end of the
function.
CVE-2021-47611:In the Linux kernel, the following vulnerability has been resolved:
mac80211: validate extended element ID is present
Before attempting to parse an extended element, verify that
the extended element ID is present.
CVE-2021-47596:In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix use-after-free bug in hclgevf_send_mbx_msg
Currently, the hns3_remove function firstly uninstall client instance,
and then uninstall acceletion engine device. The netdevice is freed in
client instance uninstall process, but acceletion engine device uninstall
process still use it to trace runtime information. This causes a use after
free problem.
So fixes it by check the instance register state to avoid use after free.
CVE-2021-47605:In the Linux kernel, the following vulnerability has been resolved:
vduse: fix memory corruption in vduse_dev_ioctl()
The &quot;config.offset&quot; comes from the user.  There needs to a check to
prevent it being out of bounds.  The &quot;config.offset&quot; and
&quot;dev-&gt;config_size&quot; variables are both type u32.  So if the offset if
out of bounds then the &quot;dev-&gt;config_size - config.offset&quot; subtraction
results in a very high u32 value.  The out of bounds offset can result
in memory corruption.
CVE-2022-48712:In the Linux kernel, the following vulnerability has been resolved:
ext4: fix error handling in ext4_fc_record_modified_inode()
Current code does not fully takes care of krealloc() error case, which
could lead to silent memory corruption or a kernel bug.  This patch
fixes that.
Also it cleans up some duplicated error handling logic from various
functions in fast_commit.c file.
CVE-2022-48724:In the Linux kernel, the following vulnerability has been resolved:
iommu/vt-d: Fix potential memory leak in intel_setup_irq_remapping()
After commit e3beca48a45b (&quot;irqdomain/treewide: Keep firmware node
unconditionally allocated&quot;). For tear down scenario, fn is only freed
after fail to allocate ir_domain, though it also should be freed in case
dmar_enable_qi returns error.
Besides free fn, irq_domain and ir_msi_domain need to be removed as well
if intel_setup_irq_remapping fails to enable queued invalidation.
Improve the rewinding path by add out_free_ir_domain and out_free_fwnode
lables per Baolu's suggestion.
CVE-2022-48771:In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Fix stale file descriptors on failed usercopy
A failing usercopy of the fence_rep object will lead to a stale entry in
the file descriptor table as put_unused_fd() won't release it. This
enables userland to refer to a dangling 'file' object through that still
valid file descriptor, leading to all kinds of use-after-free
exploitation scenarios.
Fix this by deferring the call to fd_install() until after the usercopy
has succeeded.
CVE-2022-48730:In the Linux kernel, the following vulnerability has been resolved:
dma-buf: heaps: Fix potential spectre v1 gadget
It appears like nr could be a Spectre v1 gadget as it's supplied by a
user and used as an array index. Prevent the contents
of kernel memory from being leaked to userspace via speculative
execution by using array_index_nospec.
 [sumits: added fixes and cc: stable tags]
CVE-2022-48768:In the Linux kernel, the following vulnerability has been resolved:
tracing/histogram: Fix a potential memory leak for kstrdup()
kfree() is missing on an error path to free the memory allocated by
kstrdup():
  p = param = kstrdup(data-&gt;params[i], GFP_KERNEL);
So it is better to free it via kfree(p).
CVE-2024-38388:In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda/cs_dsp_ctl: Use private_free for control cleanup
Use the control private_free callback to free the associated data
block. This ensures that the memory won't leak, whatever way the
control gets destroyed.
The original implementation didn't actually remove the ALSA
controls in hda_cs_dsp_control_remove(). It only freed the internal
tracking structure. This meant it was possible to remove/unload the
amp driver while leaving its ALSA controls still present in the
soundcard. Obviously attempting to access them could cause segfaults
or at least dereferencing stale pointers.
CVE-2022-48757:In the Linux kernel, the following vulnerability has been resolved:
net: fix information leakage in /proc/net/ptype
In one net namespace, after creating a packet socket without binding
it to a device, users in other net namespaces can observe the new
`packet_type` added by this packet socket by reading `/proc/net/ptype`
file. This is minor information leakage as packet socket is
namespace aware.
Add a net pointer in `packet_type` to keep the net namespace of
of corresponding packet socket. In `ptype_seq_show`, this net pointer
must be checked when it is not NULL.
CVE-2021-47612:In the Linux kernel, the following vulnerability has been resolved:
nfc: fix segfault in nfc_genl_dump_devices_done
When kmalloc in nfc_genl_dump_devices() fails then
nfc_genl_dump_devices_done() segfaults as below
KASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]
CPU: 0 PID: 25 Comm: kworker/0:1 Not tainted 5.16.0-rc4-01180-g2a987e65025e-dirty #5
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-6.fc35 04/01/2014
Workqueue: events netlink_sock_destruct_work
RIP: 0010:klist_iter_exit+0x26/0x80
Call Trace:
&lt;TASK&gt;
class_dev_iter_exit+0x15/0x20
nfc_genl_dump_devices_done+0x3b/0x50
genl_lock_done+0x84/0xd0
netlink_sock_destruct+0x8f/0x270
__sk_destruct+0x64/0x3b0
sk_destruct+0xa8/0xd0
__sk_free+0x2e8/0x3d0
sk_free+0x51/0x90
netlink_sock_destruct_work+0x1c/0x20
process_one_work+0x411/0x710
worker_thread+0x6fd/0xa80
CVE-2024-38551:In the Linux kernel, the following vulnerability has been resolved:
ASoC: mediatek: Assign dummy when codec not specified for a DAI link
MediaTek sound card drivers are checking whether a DAI link is present
and used on a board to assign the correct parameters and this is done
by checking the codec DAI names at probe time.
If no real codec is present, assign the dummy codec to the DAI link
to avoid NULL pointer during string comparison.
CVE-2024-38581:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/mes: fix use-after-free issue
Delete fence fallback timer to fix the ramdom
use-after-free issue.
v2: move to amdgpu_mes.c
CVE-2024-38614:In the Linux kernel, the following vulnerability has been resolved:
openrisc: traps: Don't send signals to kernel mode threads
OpenRISC exception handling sends signals to user processes on floating
point exceptions and trap instructions (for debugging) among others.
There is a bug where the trap handling logic may send signals to kernel
threads, we should not send these signals to kernel threads, if that
happens we treat it as an error.
This patch adds conditions to die if the kernel receives these
exceptions in kernel mode code.
CVE-2024-39464:In the Linux kernel, the following vulnerability has been resolved:
media: v4l: async: Fix notifier list entry init
struct v4l2_async_notifier has several list_head members, but only
waiting_list and done_list are initialized. notifier_entry was kept
'zeroed' leading to an uninitialized list_head.
This results in a NULL-pointer dereference if csi2_async_register() fails,
e.g. node for remote endpoint is disabled, and returns -ENOTCONN.
The following calls to v4l2_async_nf_unregister() results in a NULL
pointer dereference.
Add the missing list head initializer.
CVE-2024-39463:In the Linux kernel, the following vulnerability has been resolved:
9p: add missing locking around taking dentry fid list
Fix a use-after-free on dentry's d_fsdata fid list when a thread
looks up a fid through dentry while another thread unlinks it:
UAF thread:
refcount_t: addition on 0; use-after-free.
 p9_fid_get linux/./include/net/9p/client.h:262
 v9fs_fid_find+0x236/0x280 linux/fs/9p/fid.c:129
 v9fs_fid_lookup_with_uid linux/fs/9p/fid.c:181
 v9fs_fid_lookup+0xbf/0xc20 linux/fs/9p/fid.c:314
 v9fs_vfs_getattr_dotl+0xf9/0x360 linux/fs/9p/vfs_inode_dotl.c:400
 vfs_statx+0xdd/0x4d0 linux/fs/stat.c:248
Freed by:
 p9_fid_destroy (inlined)
 p9_client_clunk+0xb0/0xe0 linux/net/9p/client.c:1456
 p9_fid_put linux/./include/net/9p/client.h:278
 v9fs_dentry_release+0xb5/0x140 linux/fs/9p/vfs_dentry.c:55
 v9fs_remove+0x38f/0x620 linux/fs/9p/vfs_inode.c:518
 vfs_unlink+0x29a/0x810 linux/fs/namei.c:4335
The problem is that d_fsdata was not accessed under d_lock, because
d_release() normally is only called once the dentry is otherwise no
longer accessible but since we also call it explicitly in v9fs_remove
that lock is required:
move the hlist out of the dentry under lock then unref its fids once
they are no longer accessible.
CVE-2024-39479:In the Linux kernel, the following vulnerability has been resolved:
drm/i915/hwmon: Get rid of devm
When both hwmon and hwmon drvdata (on which hwmon depends) are device
managed resources, the expectation, on device unbind, is that hwmon will be
released before drvdata. However, in i915 there are two separate code
paths, which both release either drvdata or hwmon and either can be
released before the other. These code paths (for device unbind) are as
follows (see also the bug referenced below):
Call Trace:
release_nodes+0x11/0x70
devres_release_group+0xb2/0x110
component_unbind_all+0x8d/0xa0
component_del+0xa5/0x140
intel_pxp_tee_component_fini+0x29/0x40 [i915]
intel_pxp_fini+0x33/0x80 [i915]
i915_driver_remove+0x4c/0x120 [i915]
i915_pci_remove+0x19/0x30 [i915]
pci_device_remove+0x32/0xa0
device_release_driver_internal+0x19c/0x200
unbind_store+0x9c/0xb0
and
Call Trace:
release_nodes+0x11/0x70
devres_release_all+0x8a/0xc0
device_unbind_cleanup+0x9/0x70
device_release_driver_internal+0x1c1/0x200
unbind_store+0x9c/0xb0
This means that in i915, if use devm, we cannot gurantee that hwmon will
always be released before drvdata. Which means that we have a uaf if hwmon
sysfs is accessed when drvdata has been released but hwmon hasn't.
The only way out of this seems to be do get rid of devm_ and release/free
everything explicitly during device unbind.
v2: Change commit message and other minor code changes
v3: Cleanup from i915_hwmon_register on error (Armin Wolf)
v4: Eliminate potential static analyzer warning (Rodrigo)
    Eliminate fetch_and_zero (Jani)
v5: Restore previous logic for ddat_gt-&gt;hwmon_dev error return (Andi)
CVE-2024-39478:In the Linux kernel, the following vulnerability has been resolved:
crypto: starfive - Do not free stack buffer
RSA text data uses variable length buffer allocated in software stack.
Calling kfree on it causes undefined behaviour in subsequent operations.
CVE-2024-39502:In the Linux kernel, the following vulnerability has been resolved:
ionic: fix use after netif_napi_del()
When queues are started, netif_napi_add() and napi_enable() are called.
If there are 4 queues and only 3 queues are used for the current
configuration, only 3 queues' napi should be registered and enabled.
The ionic_qcq_enable() checks whether the .poll pointer is not NULL for
enabling only the using queue' napi. Unused queues' napi will not be
registered by netif_napi_add(), so the .poll pointer indicates NULL.
But it couldn't distinguish whether the napi was unregistered or not
because netif_napi_del() doesn't reset the .poll pointer to NULL.
So, ionic_qcq_enable() calls napi_enable() for the queue, which was
unregistered by netif_napi_del().
Reproducer:
   ethtool -L &lt;interface name&gt; rx 1 tx 1 combined 0
   ethtool -L &lt;interface name&gt; rx 0 tx 0 combined 1
   ethtool -L &lt;interface name&gt; rx 0 tx 0 combined 4
Splat looks like:
kernel BUG at net/core/dev.c:6666!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 3 PID: 1057 Comm: kworker/3:3 Not tainted 6.10.0-rc2+ #16
Workqueue: events ionic_lif_deferred_work [ionic]
RIP: 0010:napi_enable+0x3b/0x40
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
RSP: 0018:ffffb6ed83227d48 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff97560cda0828 RCX: 0000000000000029
RDX: 0000000000000001 RSI: 0000000000000000 RDI: ffff97560cda0a28
RBP: ffffb6ed83227d50 R08: 0000000000000400 R09: 0000000000000001
R10: 0000000000000001 R11: 0000000000000001 R12: 0000000000000000
R13: ffff97560ce3c1a0 R14: 0000000000000000 R15: ffff975613ba0a20
FS:  0000000000000000(0000) GS:ffff975d5f780000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f8f734ee200 CR3: 0000000103e50000 CR4: 00000000007506f0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? die+0x33/0x90
 ? do_trap+0xd9/0x100
 ? napi_enable+0x3b/0x40
 ? do_error_trap+0x83/0xb0
 ? napi_enable+0x3b/0x40
 ? napi_enable+0x3b/0x40
 ? exc_invalid_op+0x4e/0x70
 ? napi_enable+0x3b/0x40
 ? asm_exc_invalid_op+0x16/0x20
 ? napi_enable+0x3b/0x40
 ionic_qcq_enable+0xb7/0x180 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
 ionic_start_queues+0xc4/0x290 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
 ionic_link_status_check+0x11c/0x170 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
 ionic_lif_deferred_work+0x129/0x280 [ionic 59bdfc8a035436e1c4224ff7d10789e3f14643f8]
 process_one_work+0x145/0x360
 worker_thread+0x2bb/0x3d0
 ? __pfx_worker_thread+0x10/0x10
 kthread+0xcc/0x100
 ? __pfx_kthread+0x10/0x10
 ret_from_fork+0x2d/0x50
 ? __pfx_kthread+0x10/0x10
 ret_from_fork_asm+0x1a/0x30
CVE-2024-40997:In the Linux kernel, the following vulnerability has been resolved:
cpufreq: amd-pstate: fix memory leak on CPU EPP exit
The cpudata memory from kzalloc() in amd_pstate_epp_cpu_init() is
not freed in the analogous exit function, so fix that.
[ rjw: Subject and changelog edits ]
CVE-2024-40964:In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: cs35l41: Possible null pointer dereference in cs35l41_hda_unbind()
The cs35l41_hda_unbind() function clears the hda_component entry
matching it's index and then dereferences the codec pointer held in the
first element of the hda_component array, this is an issue when the
device index was 0.
Instead use the codec pointer stashed in the cs35l41_hda structure as it
will still be valid.
CVE-2022-48732:In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix off by one in BIOS boundary checking
Bounds checking when parsing init scripts embedded in the BIOS reject
access to the last byte. This causes driver initialization to fail on
Apple eMac's with GeForce 2 MX GPUs, leaving the system with no working
console.
This is probably only seen on OpenFirmware machines like PowerPC Macs
because the BIOS image provided by OF is only the used parts of the ROM,
not a power-of-two blocks read from PCI directly so PCs always have
empty bytes at the end that are never accessed.
CVE-2024-38628:In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: u_audio: Fix race condition use of controls after free during gadget unbind.
Hang on to the control IDs instead of pointers since those are correctly
handled with locks.
CVE-2024-38572:In the Linux kernel, the following vulnerability has been resolved:
wifi: ath12k: fix out-of-bound access of qmi_invoke_handler()
Currently, there is no terminator entry for ath12k_qmi_msg_handlers hence
facing below KASAN warning,
 ==================================================================
 BUG: KASAN: global-out-of-bounds in qmi_invoke_handler+0xa4/0x148
 Read of size 8 at addr ffffffd00a6428d8 by task kworker/u8:2/1273
 CPU: 0 PID: 1273 Comm: kworker/u8:2 Not tainted 5.4.213 #0
 Workqueue: qmi_msg_handler qmi_data_ready_work
 Call trace:
  dump_backtrace+0x0/0x20c
  show_stack+0x14/0x1c
  dump_stack+0xe0/0x138
  print_address_description.isra.5+0x30/0x330
  __kasan_report+0x16c/0x1bc
  kasan_report+0xc/0x14
  __asan_load8+0xa8/0xb0
  qmi_invoke_handler+0xa4/0x148
  qmi_handle_message+0x18c/0x1bc
  qmi_data_ready_work+0x4ec/0x528
  process_one_work+0x2c0/0x440
  worker_thread+0x324/0x4b8
  kthread+0x210/0x228
  ret_from_fork+0x10/0x18
 The address belongs to the variable:
  ath12k_mac_mon_status_filter_default+0x4bd8/0xfffffffffffe2300 [ath12k]
 [...]
 ==================================================================
Add a dummy terminator entry at the end to assist the qmi_invoke_handler()
in traversing up to the terminator entry without accessing an
out-of-boundary index.
Tested-on: QCN9274 hw2.0 PCI WLAN.WBE.1.0.1-00029-QCAHKSWPL_SILICONZ-1
CVE-2024-27416:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_event: Fix handling of HCI_EV_IO_CAPA_REQUEST
If we received HCI_EV_IO_CAPA_REQUEST while
HCI_OP_READ_REMOTE_EXT_FEATURES is yet to be responded assume the remote
does support SSP since otherwise this event shouldn't be generated.
CVE-2022-48822:In the Linux kernel, the following vulnerability has been resolved:
usb: f_fs: Fix use-after-free for epfile
Consider a case where ffs_func_eps_disable is called from
ffs_func_disable as part of composition switch and at the
same time ffs_epfile_release get called from userspace.
ffs_epfile_release will free up the read buffer and call
ffs_data_closed which in turn destroys ffs-&gt;epfiles and
mark it as NULL. While this was happening the driver has
already initialized the local epfile in ffs_func_eps_disable
which is now freed and waiting to acquire the spinlock. Once
spinlock is acquired the driver proceeds with the stale value
of epfile and tries to free the already freed read buffer
causing use-after-free.
Following is the illustration of the race:
      CPU1                                  CPU2
   ffs_func_eps_disable
   epfiles (local copy)
					ffs_epfile_release
					ffs_data_closed
					if (last file closed)
					ffs_data_reset
					ffs_data_clear
					ffs_epfiles_destroy
spin_lock
dereference epfiles
Fix this races by taking epfiles local copy &amp; assigning it under
spinlock and if epfiles(local) is null then update it in ffs-&gt;epfiles
then finally destroy it.
Extending the scope further from the race, protecting the ep related
structures, and concurrent accesses.
CVE-2024-36935:In the Linux kernel, the following vulnerability has been resolved:
ice: ensure the copied buf is NUL terminated
Currently, we allocate a count-sized kernel buffer and copy count bytes
from userspace to that buffer. Later, we use sscanf on this buffer but we
don't ensure that the string is terminated inside the buffer, this can lead
to OOB read when using sscanf. Fix this issue by using memdup_user_nul
instead of memdup_user.
CVE-2024-36955:In the Linux kernel, the following vulnerability has been resolved:
ALSA: hda: intel-sdw-acpi: fix usage of device_get_named_child_node()
The documentation for device_get_named_child_node() mentions this
important point:
&quot;
The caller is responsible for calling fwnode_handle_put() on the
returned fwnode pointer.
&quot;
Add fwnode_handle_put() to avoid a leaked reference.
CVE-2024-36956:In the Linux kernel, the following vulnerability has been resolved:
thermal/debugfs: Free all thermal zone debug memory on zone removal
Because thermal_debug_tz_remove() does not free all memory allocated for
thermal zone diagnostics, some of that memory becomes unreachable after
freeing the thermal zone's struct thermal_debugfs object.
Address this by making thermal_debug_tz_remove() free all of the memory
in question.
Cc :6.8+ &lt;stable@vger.kernel.org&gt; # 6.8+
CVE-2022-48807:In the Linux kernel, the following vulnerability has been resolved:
ice: Fix KASAN error in LAG NETDEV_UNREGISTER handler
Currently, the same handler is called for both a NETDEV_BONDING_INFO
LAG unlink notification as for a NETDEV_UNREGISTER call.  This is
causing a problem though, since the netdev_notifier_info passed has
a different structure depending on which event is passed.  The problem
manifests as a call trace from a BUG: KASAN stack-out-of-bounds error.
Fix this by creating a handler specific to NETDEV_UNREGISTER that only
is passed valid elements in the netdev_notifier_info struct for the
NETDEV_UNREGISTER event.
Also included is the removal of an unbalanced dev_put on the peer_netdev
and related braces.
CVE-2024-36973:In the Linux kernel, the following vulnerability has been resolved:
misc: microchip: pci1xxxx: fix double free in the error handling of gp_aux_bus_probe()
When auxiliary_device_add() returns error and then calls
auxiliary_device_uninit(), callback function
gp_auxiliary_device_release() calls ida_free() and
kfree(aux_device_wrapper) to free memory. We should't
call them again in the error handling path.
Fix this by skipping the redundant cleanup functions.
CVE-2022-48837:In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: rndis: prevent integer overflow in rndis_set_response()
If &quot;BufOffset&quot; is very large the &quot;BufOffset + 8&quot; operation can have an
integer overflow.
CVE-2024-36951:In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: range check cp bad op exception interrupts
Due to a CP interrupt bug, bad packet garbage exception codes are raised.
Do a range check so that the debugger and runtime do not receive garbage
codes.
Update the user api to guard exception code type checking as well.
CVE-2024-26978:In the Linux kernel, the following vulnerability has been resolved:
serial: max310x: fix NULL pointer dereference in I2C instantiation
When trying to instantiate a max14830 device from userspace:
    echo max14830 0x60 &gt; /sys/bus/i2c/devices/i2c-2/new_device
we get the following error:
    Unable to handle kernel NULL pointer dereference at virtual address...
    ...
    Call trace:
        max310x_i2c_probe+0x48/0x170 [max310x]
        i2c_device_probe+0x150/0x2a0
    ...
Add check for validity of devtype to prevent the error, and abort probe
with a meaningful error message.
CVE-2024-36967:In the Linux kernel, the following vulnerability has been resolved:
KEYS: trusted: Fix memory leak in tpm2_key_encode()
'scratch' is never freed. Fix this by calling kfree() in the success, and
in the error case.
CVE-2024-36031:In the Linux kernel, the following vulnerability has been resolved:
keys: Fix overwrite of key expiration on instantiation
The expiry time of a key is unconditionally overwritten during
instantiation, defaulting to turn it permanent. This causes a problem
for DNS resolution as the expiration set by user-space is overwritten to
TIME64_MAX, disabling further DNS updates. Fix this by restoring the
condition that key_set_expiry is only called when the pre-parser sets a
specific expiry.
CVE-2024-36979:In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mst: fix vlan use-after-free
syzbot reported a suspicious rcu usage[1] in bridge's mst code. While
fixing it I noticed that nothing prevents a vlan to be freed while
walking the list from the same path (br forward delay timer). Fix the rcu
usage and also make sure we are not accessing freed memory by making
br_mst_vlan_set_state use rcu read lock.
[1]
 WARNING: suspicious RCU usage
 6.9.0-rc6-syzkaller #0 Not tainted
 -----------------------------
 net/bridge/br_private.h:1599 suspicious rcu_dereference_protected() usage!
 ...
 stack backtrace:
 CPU: 1 PID: 8017 Comm: syz-executor.1 Not tainted 6.9.0-rc6-syzkaller #0
 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
 Call Trace:
  &lt;IRQ&gt;
  __dump_stack lib/dump_stack.c:88 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:114
  lockdep_rcu_suspicious+0x221/0x340 kernel/locking/lockdep.c:6712
  nbp_vlan_group net/bridge/br_private.h:1599 [inline]
  br_mst_set_state+0x1ea/0x650 net/bridge/br_mst.c:105
  br_set_state+0x28a/0x7b0 net/bridge/br_stp.c:47
  br_forward_delay_timer_expired+0x176/0x440 net/bridge/br_stp_timer.c:88
  call_timer_fn+0x18e/0x650 kernel/time/timer.c:1793
  expire_timers kernel/time/timer.c:1844 [inline]
  __run_timers kernel/time/timer.c:2418 [inline]
  __run_timer_base+0x66a/0x8e0 kernel/time/timer.c:2429
  run_timer_base kernel/time/timer.c:2438 [inline]
  run_timer_softirq+0xb7/0x170 kernel/time/timer.c:2448
  __do_softirq+0x2c6/0x980 kernel/softirq.c:554
  invoke_softirq kernel/softirq.c:428 [inline]
  __irq_exit_rcu+0xf2/0x1c0 kernel/softirq.c:633
  irq_exit_rcu+0x9/0x30 kernel/softirq.c:645
  instr_sysvec_apic_timer_interrupt arch/x86/kernel/apic/apic.c:1043 [inline]
  sysvec_apic_timer_interrupt+0xa6/0xc0 arch/x86/kernel/apic/apic.c:1043
  &lt;/IRQ&gt;
  &lt;TASK&gt;
 asm_sysvec_apic_timer_interrupt+0x1a/0x20 arch/x86/include/asm/idtentry.h:702
 RIP: 0010:lock_acquire+0x264/0x550 kernel/locking/lockdep.c:5758
 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
 RSP: 0018:ffffc90013657100 EFLAGS: 00000206
 RAX: 0000000000000001 RBX: 1ffff920026cae2c RCX: 0000000000000001
 RDX: dffffc0000000000 RSI: ffffffff8bcaca00 RDI: ffffffff8c1eaa60
 RBP: ffffc90013657260 R08: ffffffff92efe507 R09: 1ffffffff25dfca0
 R10: dffffc0000000000 R11: fffffbfff25dfca1 R12: 1ffff920026cae28
 R13: dffffc0000000000 R14: ffffc90013657160 R15: 0000000000000246
CVE-2024-36881:In the Linux kernel, the following vulnerability has been resolved:
mm/userfaultfd: reset ptes when close() for wr-protected ones
Userfaultfd unregister includes a step to remove wr-protect bits from all
the relevant pgtable entries, but that only covered an explicit
UFFDIO_UNREGISTER ioctl, not a close() on the userfaultfd itself.  Cover
that too.  This fixes a WARN trace.
The only user visible side effect is the user can observe leftover
wr-protect bits even if the user close()ed on an userfaultfd when
releasing the last reference of it.  However hopefully that should be
harmless, and nothing bad should happen even if so.
This change is now more important after the recent page-table-check
patch we merged in mm-unstable (446dd9ad37d0 (&quot;mm/page_table_check:
support userfault wr-protect entries&quot;)), as we'll do sanity check on
uffd-wp bits without vma context.  So it's better if we can 100%
guarantee no uffd-wp bit leftovers, to make sure each report will be
valid.
CVE-2024-34030:In the Linux kernel, the following vulnerability has been resolved:
PCI: of_property: Return error for int_map allocation failure
Return -ENOMEM from of_pci_prop_intr_map() if kcalloc() fails to prevent a
NULL pointer dereference in this case.
[bhelgaas: commit log]
CVE-2024-38385:In the Linux kernel, the following vulnerability has been resolved:
genirq/irqdesc: Prevent use-after-free in irq_find_at_or_after()
irq_find_at_or_after() dereferences the interrupt descriptor which is
returned by mt_find() while neither holding sparse_irq_lock nor RCU read
lock, which means the descriptor can be freed between mt_find() and the
dereference:
    CPU0                            CPU1
    desc = mt_find()
                                    delayed_free_desc(desc)
    irq_desc_get_irq(desc)
The use-after-free is reported by KASAN:
    Call trace:
     irq_get_next_irq+0x58/0x84
     show_stat+0x638/0x824
     seq_read_iter+0x158/0x4ec
     proc_reg_read_iter+0x94/0x12c
     vfs_read+0x1e0/0x2c8
    Freed by task 4471:
     slab_free_freelist_hook+0x174/0x1e0
     __kmem_cache_free+0xa4/0x1dc
     kfree+0x64/0x128
     irq_kobj_release+0x28/0x3c
     kobject_put+0xcc/0x1e0
     delayed_free_desc+0x14/0x2c
     rcu_do_batch+0x214/0x720
Guard the access with a RCU read lock section.
CVE-2024-39485:In the Linux kernel, the following vulnerability has been resolved:
media: v4l: async: Properly re-initialise notifier entry in unregister
The notifier_entry of a notifier is not re-initialised after unregistering
the notifier. This leads to dangling pointers being left there so use
list_del_init() to return the notifier_entry an empty list.
CVE-2024-40957:In the Linux kernel, the following vulnerability has been resolved:
seg6: fix parameter passing when calling NF_HOOK() in End.DX4 and End.DX6 behaviors
input_action_end_dx4() and input_action_end_dx6() are called NF_HOOK() for
PREROUTING hook, in PREROUTING hook, we should passing a valid indev,
and a NULL outdev to NF_HOOK(), otherwise may trigger a NULL pointer
dereference, as below:
    [74830.647293] BUG: kernel NULL pointer dereference, address: 0000000000000090
    [74830.655633] #PF: supervisor read access in kernel mode
    [74830.657888] #PF: error_code(0x0000) - not-present page
    [74830.659500] PGD 0 P4D 0
    [74830.660450] Oops: 0000 [#1] PREEMPT SMP PTI
    ...
    [74830.664953] Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011
    [74830.666569] RIP: 0010:rpfilter_mt+0x44/0x15e [ipt_rpfilter]
    ...
    [74830.689725] Call Trace:
    [74830.690402]  &lt;IRQ&gt;
    [74830.690953]  ? show_trace_log_lvl+0x1c4/0x2df
    [74830.692020]  ? show_trace_log_lvl+0x1c4/0x2df
    [74830.693095]  ? ipt_do_table+0x286/0x710 [ip_tables]
    [74830.694275]  ? __die_body.cold+0x8/0xd
    [74830.695205]  ? page_fault_oops+0xac/0x140
    [74830.696244]  ? exc_page_fault+0x62/0x150
    [74830.697225]  ? asm_exc_page_fault+0x22/0x30
    [74830.698344]  ? rpfilter_mt+0x44/0x15e [ipt_rpfilter]
    [74830.699540]  ipt_do_table+0x286/0x710 [ip_tables]
    [74830.700758]  ? ip6_route_input+0x19d/0x240
    [74830.701752]  nf_hook_slow+0x3f/0xb0
    [74830.702678]  input_action_end_dx4+0x19b/0x1e0
    [74830.703735]  ? input_action_end_t+0xe0/0xe0
    [74830.704734]  seg6_local_input_core+0x2d/0x60
    [74830.705782]  lwtunnel_input+0x5b/0xb0
    [74830.706690]  __netif_receive_skb_one_core+0x63/0xa0
    [74830.707825]  process_backlog+0x99/0x140
    [74830.709538]  __napi_poll+0x2c/0x160
    [74830.710673]  net_rx_action+0x296/0x350
    [74830.711860]  __do_softirq+0xcb/0x2ac
    [74830.713049]  do_softirq+0x63/0x90
input_action_end_dx4() passing a NULL indev to NF_HOOK(), and finally
trigger a NULL dereference in rpfilter_mt()-&gt;rpfilter_is_loopback():
    static bool
    rpfilter_is_loopback(const struct sk_buff *skb,
          	       const struct net_device *in)
    {
            // in is NULL
            return skb-&gt;pkt_type == PACKET_LOOPBACK ||
          	 in-&gt;flags &amp; IFF_LOOPBACK;
    }
CVE-2024-40923:In the Linux kernel, the following vulnerability has been resolved:
vmxnet3: disable rx data ring on dma allocation failure
When vmxnet3_rq_create() fails to allocate memory for rq-&gt;data_ring.base,
the subsequent call to vmxnet3_rq_destroy_all_rxdataring does not reset
rq-&gt;data_ring.desc_size for the data ring that failed, which presumably
causes the hypervisor to reference it on packet reception.
To fix this bug, rq-&gt;data_ring.desc_size needs to be set to 0 to tell
the hypervisor to disable this feature.
[   95.436876] kernel BUG at net/core/skbuff.c:207!
[   95.439074] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
[   95.440411] CPU: 7 PID: 0 Comm: swapper/7 Not tainted 6.9.3-dirty #1
[   95.441558] Hardware name: VMware, Inc. VMware Virtual
Platform/440BX Desktop Reference Platform, BIOS 6.00 12/12/2018
[   95.443481] RIP: 0010:skb_panic+0x4d/0x4f
[   95.444404] Code: 4f 70 50 8b 87 c0 00 00 00 50 8b 87 bc 00 00 00 50
ff b7 d0 00 00 00 4c 8b 8f c8 00 00 00 48 c7 c7 68 e8 be 9f e8 63 58 f9
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
[   95.447684] RSP: 0018:ffffa13340274dd0 EFLAGS: 00010246
[   95.448762] RAX: 0000000000000089 RBX: ffff8fbbc72b02d0 RCX: 000000000000083f
[   95.450148] RDX: 0000000000000000 RSI: 00000000000000f6 RDI: 000000000000083f
[   95.451520] RBP: 000000000000002d R08: 0000000000000000 R09: ffffa13340274c60
[   95.452886] R10: ffffffffa04ed468 R11: 0000000000000002 R12: 0000000000000000
[   95.454293] R13: ffff8fbbdab3c2d0 R14: ffff8fbbdbd829e0 R15: ffff8fbbdbd809e0
[   95.455682] FS:  0000000000000000(0000) GS:ffff8fbeefd80000(0000) knlGS:0000000000000000
[   95.457178] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   95.458340] CR2: 00007fd0d1f650c8 CR3: 0000000115f28000 CR4: 00000000000406f0
[   95.459791] Call Trace:
[   95.460515]  &lt;IRQ&gt;
[   95.461180]  ? __die_body.cold+0x19/0x27
[   95.462150]  ? die+0x2e/0x50
[   95.462976]  ? do_trap+0xca/0x110
[   95.463973]  ? do_error_trap+0x6a/0x90
[   95.464966]  ? skb_panic+0x4d/0x4f
[   95.465901]  ? exc_invalid_op+0x50/0x70
[   95.466849]  ? skb_panic+0x4d/0x4f
[   95.467718]  ? asm_exc_invalid_op+0x1a/0x20
[   95.468758]  ? skb_panic+0x4d/0x4f
[   95.469655]  skb_put.cold+0x10/0x10
[   95.470573]  vmxnet3_rq_rx_complete+0x862/0x11e0 [vmxnet3]
[   95.471853]  vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3]
[   95.473185]  __napi_poll+0x2b/0x160
[   95.474145]  net_rx_action+0x2c6/0x3b0
[   95.475115]  handle_softirqs+0xe7/0x2a0
[   95.476122]  __irq_exit_rcu+0x97/0xb0
[   95.477109]  common_interrupt+0x85/0xa0
[   95.478102]  &lt;/IRQ&gt;
[   95.478846]  &lt;TASK&gt;
[   95.479603]  asm_common_interrupt+0x26/0x40
[   95.480657] RIP: 0010:pv_native_safe_halt+0xf/0x20
[   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
[   95.485563] RSP: 0018:ffffa133400ffe58 EFLAGS: 00000246
[   95.486882] RAX: 0000000000004000 RBX: ffff8fbbc1d14064 RCX: 0000000000000000
[   95.488477] RDX: ffff8fbeefd80000 RSI: ffff8fbbc1d14000 RDI: 0000000000000001
[   95.490067] RBP: ffff8fbbc1d14064 R08: ffffffffa0652260 R09: 00000000000010d3
[   95.491683] R10: 0000000000000018 R11: ffff8fbeefdb4764 R12: ffffffffa0652260
[   95.493389] R13: ffffffffa06522e0 R14: 0000000000000001 R15: 0000000000000000
[   95.495035]  acpi_safe_halt+0x14/0x20
[   95.496127]  acpi_idle_do_entry+0x2f/0x50
[   95.497221]  acpi_idle_enter+0x7f/0xd0
[   95.498272]  cpuidle_enter_state+0x81/0x420
[   95.499375]  cpuidle_enter+0x2d/0x40
[   95.500400]  do_idle+0x1e5/0x240
[   95.501385]  cpu_startup_entry+0x29/0x30
[   95.502422]  start_secondary+0x11c/0x140
[   95.503454]  common_startup_64+0x13e/0x141
[   95.504466]  &lt;/TASK&gt;
[   95.505197] Modules linked in: 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_ip
---truncated---
CVE-2024-40918:In the Linux kernel, the following vulnerability has been resolved:
parisc: Try to fix random segmentation faults in package builds
PA-RISC systems with PA8800 and PA8900 processors have had problems
with random segmentation faults for many years.  Systems with earlier
processors are much more stable.
Systems with PA8800 and PA8900 processors have a large L2 cache which
needs per page flushing for decent performance when a large range is
flushed. The combined cache in these systems is also more sensitive to
non-equivalent aliases than the caches in earlier systems.
The majority of random segmentation faults that I have looked at
appear to be memory corruption in memory allocated using mmap and
malloc.
My first attempt at fixing the random faults didn't work. On
reviewing the cache code, I realized that there were two issues
which the existing code didn't handle correctly. Both relate
to cache move-in. Another issue is that the present bit in PTEs
is racy.
1) PA-RISC caches have a mind of their own and they can speculatively
load data and instructions for a page as long as there is a entry in
the TLB for the page which allows move-in. TLBs are local to each
CPU. Thus, the TLB entry for a page must be purged before flushing
the page. This is particularly important on SMP systems.
In some of the flush routines, the flush routine would be called
and then the TLB entry would be purged. This was because the flush
routine needed the TLB entry to do the flush.
2) My initial approach to trying the fix the random faults was to
try and use flush_cache_page_if_present for all flush operations.
This actually made things worse and led to a couple of hardware
lockups. It finally dawned on me that some lines weren't being
flushed because the pte check code was racy. This resulted in
random inequivalent mappings to physical pages.
The __flush_cache_page tmpalias flush sets up its own TLB entry
and it doesn't need the existing TLB entry. As long as we can find
the pte pointer for the vm page, we can get the pfn and physical
address of the page. We can also purge the TLB entry for the page
before doing the flush. Further, __flush_cache_page uses a special
TLB entry that inhibits cache move-in.
When switching page mappings, we need to ensure that lines are
removed from the cache.  It is not sufficient to just flush the
lines to memory as they may come back.
This made it clear that we needed to implement all the required
flush operations using tmpalias routines. This includes flushes
for user and kernel pages.
After modifying the code to use tmpalias flushes, it became clear
that the random segmentation faults were not fully resolved. The
frequency of faults was worse on systems with a 64 MB L2 (PA8900)
and systems with more CPUs (rp4440).
The warning that I added to flush_cache_page_if_present to detect
pages that couldn't be flushed triggered frequently on some systems.
Helge and I looked at the pages that couldn't be flushed and found
that the PTE was either cleared or for a swap page. Ignoring pages
that were swapped out seemed okay but pages with cleared PTEs seemed
problematic.
I looked at routines related to pte_clear and noticed ptep_clear_flush.
The default implementation just flushes the TLB entry. However, it was
obvious that on parisc we need to flush the cache page as well. If
we don't flush the cache page, stale lines will be left in the cache
and cause random corruption. Once a PTE is cleared, there is no way
to find the physical address associated with the PTE and flush the
associated page at a later time.
I implemented an updated change with a parisc specific version of
ptep_clear_flush. It fixed the random data corruption on Helge's rp4440
and rp3440, as well as on my c8000.
At this point, I realized that I could restore the code where we only
flush in flush_cache_page_if_present if the page has been accessed.
However, for this, we also need to flush the cache when the accessed
bit is cleared in
---truncated---
CVE-2024-40936:In the Linux kernel, the following vulnerability has been resolved:
cxl/region: Fix memregion leaks in devm_cxl_add_region()
Move the mode verification to __create_region() before allocating the
memregion to avoid the memregion leaks.
CVE-2024-40975:In the Linux kernel, the following vulnerability has been resolved:
platform/x86: x86-android-tablets: Unregister devices in reverse order
Not all subsystems support a device getting removed while there are
still consumers of the device with a reference to the device.
One example of this is the regulator subsystem. If a regulator gets
unregistered while there are still drivers holding a reference
a WARN() at drivers/regulator/core.c:5829 triggers, e.g.:
 WARNING: CPU: 1 PID: 1587 at drivers/regulator/core.c:5829 regulator_unregister
 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
 RIP: 0010:regulator_unregister
 Call Trace:
  &lt;TASK&gt;
  regulator_unregister
  devres_release_group
  i2c_device_remove
  device_release_driver_internal
  bus_remove_device
  device_del
  device_unregister
  x86_android_tablet_remove
On the Lenovo Yoga Tablet 2 series the bq24190 charger chip also provides
a 5V boost converter output for powering USB devices connected to the micro
USB port, the bq24190-charger driver exports this as a Vbus regulator.
On the 830 (8&quot;) and 1050 (&quot;10&quot;) models this regulator is controlled by
a platform_device and x86_android_tablet_remove() removes platform_device-s
before i2c_clients so the consumer gets removed first.
But on the 1380 (13&quot;) model there is a lc824206xa micro-USB switch
connected over I2C and the extcon driver for that controls the regulator.
The bq24190 i2c-client *must* be registered first, because that creates
the regulator with the lc824206xa listed as its consumer. If the regulator
has not been registered yet the lc824206xa driver will end up getting
a dummy regulator.
Since in this case both the regulator provider and consumer are I2C
devices, the only way to ensure that the consumer is unregistered first
is to unregister the I2C devices in reverse order of in which they were
created.
For consistency and to avoid similar problems in the future change
x86_android_tablet_remove() to unregister all device types in reverse
order.
CVE-2024-40951:In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix NULL pointer dereference in ocfs2_abort_trigger()
bdev-&gt;bd_super has been removed and commit 8887b94d9322 change the usage
from bdev-&gt;bd_super to b_assoc_map-&gt;host-&gt;i_sb.  Since ocfs2 hasn't set
bh-&gt;b_assoc_map, it will trigger NULL pointer dereference when calling
into ocfs2_abort_trigger().
Actually this was pointed out in history, see commit 74e364ad1b13.  But
I've made a mistake when reviewing commit 8887b94d9322 and then
re-introduce this regression.
Since we cannot revive bdev in buffer head, so fix this issue by
initializing all types of ocfs2 triggers when fill super, and then get the
specific ocfs2 trigger from ocfs2_caching_info when access journal.
[joseph.qi@linux.alibaba.com: v2]
  Link: https://lkml.kernel.org/r/20240602112045.1112708-1-joseph.qi@linux.alibaba.com
CVE-2024-40977:In the Linux kernel, the following vulnerability has been resolved:
wifi: mt76: mt7921s: fix potential hung tasks during chip recovery
During chip recovery (e.g. chip reset), there is a possible situation that
kernel worker reset_work is holding the lock and waiting for kernel thread
stat_worker to be parked, while stat_worker is waiting for the release of
the same lock.
It causes a deadlock resulting in the dumping of hung tasks messages and
possible rebooting of the device.
This patch prevents the execution of stat_worker during the chip recovery.
CVE-2022-48775:In the Linux kernel, the following vulnerability has been resolved:
Drivers: hv: vmbus: Fix memory leak in vmbus_add_channel_kobj
kobject_init_and_add() takes reference even when it fails.
According to the doc of kobject_init_and_add()：
   If this function returns an error, kobject_put() must be called to
   properly clean up the memory associated with the object.
Fix memory leak by calling kobject_put().
CVE-2022-48788:In the Linux kernel, the following vulnerability has been resolved:
nvme-rdma: fix possible use-after-free in transport error_recovery work
While nvme_rdma_submit_async_event_work is checking the ctrl and queue
state before preparing the AER command and scheduling io_work, in order
to fully prevent a race where this check is not reliable the error
recovery work must flush async_event_work before continuing to destroy
the admin queue after setting the ctrl state to RESETTING such that
there is no race .submit_async_event and the error recovery handler
itself changing the ctrl state.
CVE-2022-48865:In the Linux kernel, the following vulnerability has been resolved:
tipc: fix kernel panic when enabling bearer
When enabling a bearer on a node, a kernel panic is observed:
[    4.498085] RIP: 0010:tipc_mon_prep+0x4e/0x130 [tipc]
...
[    4.520030] Call Trace:
[    4.520689]  &lt;IRQ&gt;
[    4.521236]  tipc_link_build_proto_msg+0x375/0x750 [tipc]
[    4.522654]  tipc_link_build_state_msg+0x48/0xc0 [tipc]
[    4.524034]  __tipc_node_link_up+0xd7/0x290 [tipc]
[    4.525292]  tipc_rcv+0x5da/0x730 [tipc]
[    4.526346]  ? __netif_receive_skb_core+0xb7/0xfc0
[    4.527601]  tipc_l2_rcv_msg+0x5e/0x90 [tipc]
[    4.528737]  __netif_receive_skb_list_core+0x20b/0x260
[    4.530068]  netif_receive_skb_list_internal+0x1bf/0x2e0
[    4.531450]  ? dev_gro_receive+0x4c2/0x680
[    4.532512]  napi_complete_done+0x6f/0x180
[    4.533570]  virtnet_poll+0x29c/0x42e [virtio_net]
...
The node in question is receiving activate messages in another
thread after changing bearer status to allow message sending/
receiving in current thread:
         thread 1           |              thread 2
         --------           |              --------
                            |
tipc_enable_bearer()        |
  test_and_set_bit_lock()   |
    tipc_bearer_xmit_skb()  |
                            | tipc_l2_rcv_msg()
                            |   tipc_rcv()
                            |     __tipc_node_link_up()
                            |       tipc_link_build_state_msg()
                            |         tipc_link_build_proto_msg()
                            |           tipc_mon_prep()
                            |           {
                            |             ...
                            |             // null-pointer dereference
                            |             u16 gen = mon-&gt;dom_gen;
                            |             ...
                            |           }
  // Not being executed yet |
  tipc_mon_create()         |
  {                         |
    ...                     |
    // allocate             |
    mon = kzalloc();        |
    ...                     |
  }                         |
Monitoring pointer in thread 2 is dereferenced before monitoring data
is allocated in thread 1. This causes kernel panic.
This commit fixes it by allocating the monitoring data before enabling
the bearer to receive messages.
CVE-2022-48856:In the Linux kernel, the following vulnerability has been resolved:
gianfar: ethtool: Fix refcount leak in gfar_get_ts_info
The of_find_compatible_node() function returns a node pointer with
refcount incremented, We should use of_node_put() on it when done
Add the missing of_node_put() to release the refcount.
CVE-2022-48838:In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: Fix use-after-free bug by not setting udc-&gt;dev.driver
The syzbot fuzzer found a use-after-free bug:
BUG: KASAN: use-after-free in dev_uevent+0x712/0x780 drivers/base/core.c:2320
Read of size 8 at addr ffff88802b934098 by task udevd/3689
CPU: 2 PID: 3689 Comm: udevd Not tainted 5.17.0-rc4-syzkaller-00229-g4f12b742eb2b #0
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.14.0-2 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xcd/0x134 lib/dump_stack.c:106
 print_address_description.constprop.0.cold+0x8d/0x303 mm/kasan/report.c:255
 __kasan_report mm/kasan/report.c:442 [inline]
 kasan_report.cold+0x83/0xdf mm/kasan/report.c:459
 dev_uevent+0x712/0x780 drivers/base/core.c:2320
 uevent_show+0x1b8/0x380 drivers/base/core.c:2391
 dev_attr_show+0x4b/0x90 drivers/base/core.c:2094
Although the bug manifested in the driver core, the real cause was a
race with the gadget core.  dev_uevent() does:
	if (dev-&gt;driver)
		add_uevent_var(env, &quot;DRIVER=%s&quot;, dev-&gt;driver-&gt;name);
and between the test and the dereference of dev-&gt;driver, the gadget
core sets dev-&gt;driver to NULL.
The race wouldn't occur if the gadget core registered its devices on
a real bus, using the standard synchronization techniques of the
driver core.  However, it's not necessary to make such a large change
in order to fix this bug; all we need to do is make sure that
udc-&gt;dev.driver is always NULL.
In fact, there is no reason for udc-&gt;dev.driver ever to be set to
anything, let alone to the value it currently gets: the address of the
gadget's driver.  After all, a gadget driver only knows how to manage
a gadget, not how to manage a UDC.
This patch simply removes the statements in the gadget core that touch
udc-&gt;dev.driver.
CVE-2024-38593:In the Linux kernel, the following vulnerability has been resolved:
net: micrel: Fix receiving the timestamp in the frame for lan8841
The blamed commit started to use the ptp workqueue to get the second
part of the timestamp. And when the port was set down, then this
workqueue is stopped. But if the config option NETWORK_PHY_TIMESTAMPING
is not enabled, then the ptp_clock is not initialized so then it would
crash when it would try to access the delayed work.
So then basically by setting up and then down the port, it would crash.
The fix consists in checking if the ptp_clock is initialized and only
then cancel the delayed work.
CVE-2024-36962:In the Linux kernel, the following vulnerability has been resolved:
net: ks8851: Queue RX packets in IRQ handler instead of disabling BHs
Currently the driver uses local_bh_disable()/local_bh_enable() in its
IRQ handler to avoid triggering net_rx_action() softirq on exit from
netif_rx(). The net_rx_action() could trigger this driver .start_xmit
callback, which is protected by the same lock as the IRQ handler, so
calling the .start_xmit from netif_rx() from the IRQ handler critical
section protected by the lock could lead to an attempt to claim the
already claimed lock, and a hang.
The local_bh_disable()/local_bh_enable() approach works only in case
the IRQ handler is protected by a spinlock, but does not work if the
IRQ handler is protected by mutex, i.e. this works for KS8851 with
Parallel bus interface, but not for KS8851 with SPI bus interface.
Remove the BH manipulation and instead of calling netif_rx() inside
the IRQ handler code protected by the lock, queue all the received
SKBs in the IRQ handler into a queue first, and once the IRQ handler
exits the critical section protected by the lock, dequeue all the
queued SKBs and push them all into netif_rx(). At this point, it is
safe to trigger the net_rx_action() softirq, since the netif_rx()
call is outside of the lock that protects the IRQ handler.
CVE-2024-38557:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Reload only IB representors upon lag disable/enable
On lag disable, the bond IB device along with all of its
representors are destroyed, and then the slaves' representors get reloaded.
In case the slave IB representor load fails, the eswitch error flow
unloads all representors, including ethernet representors, where the
netdevs get detached and removed from lag bond. Such flow is inaccurate
as the lag driver is not responsible for loading/unloading ethernet
representors. Furthermore, the flow described above begins by holding
lag lock to prevent bond changes during disable flow. However, when
reaching the ethernet representors detachment from lag, the lag lock is
required again, triggering the following deadlock:
Call trace:
__switch_to+0xf4/0x148
__schedule+0x2c8/0x7d0
schedule+0x50/0xe0
schedule_preempt_disabled+0x18/0x28
__mutex_lock.isra.13+0x2b8/0x570
__mutex_lock_slowpath+0x1c/0x28
mutex_lock+0x4c/0x68
mlx5_lag_remove_netdev+0x3c/0x1a0 [mlx5_core]
mlx5e_uplink_rep_disable+0x70/0xa0 [mlx5_core]
mlx5e_detach_netdev+0x6c/0xb0 [mlx5_core]
mlx5e_netdev_change_profile+0x44/0x138 [mlx5_core]
mlx5e_netdev_attach_nic_profile+0x28/0x38 [mlx5_core]
mlx5e_vport_rep_unload+0x184/0x1b8 [mlx5_core]
mlx5_esw_offloads_rep_load+0xd8/0xe0 [mlx5_core]
mlx5_eswitch_reload_reps+0x74/0xd0 [mlx5_core]
mlx5_disable_lag+0x130/0x138 [mlx5_core]
mlx5_lag_disable_change+0x6c/0x70 [mlx5_core] // hold ldev-&gt;lock
mlx5_devlink_eswitch_mode_set+0xc0/0x410 [mlx5_core]
devlink_nl_cmd_eswitch_set_doit+0xdc/0x180
genl_family_rcv_msg_doit.isra.17+0xe8/0x138
genl_rcv_msg+0xe4/0x220
netlink_rcv_skb+0x44/0x108
genl_rcv+0x40/0x58
netlink_unicast+0x198/0x268
netlink_sendmsg+0x1d4/0x418
sock_sendmsg+0x54/0x60
__sys_sendto+0xf4/0x120
__arm64_sys_sendto+0x30/0x40
el0_svc_common+0x8c/0x120
do_el0_svc+0x30/0xa0
el0_svc+0x20/0x30
el0_sync_handler+0x90/0xb8
el0_sync+0x160/0x180
Thus, upon lag enable/disable, load and unload only the IB representors
of the slaves preventing the deadlock mentioned above.
While at it, refactor the mlx5_esw_offloads_rep_load() function to have
a static helper method for its internal logic, in symmetry with the
representor unload design.
CVE-2024-38562:In the Linux kernel, the following vulnerability has been resolved:
wifi: nl80211: Avoid address calculations via out of bounds array indexing
Before request-&gt;channels[] can be used, request-&gt;n_channels must be set.
Additionally, address calculations for memory after the &quot;channels&quot; array
need to be calculated from the allocation base (&quot;request&quot;) rather than
via the first &quot;out of bounds&quot; index of &quot;channels&quot;, otherwise run-time
bounds checking will throw a warning.
CVE-2024-38604:In the Linux kernel, the following vulnerability has been resolved:
block: refine the EOF check in blkdev_iomap_begin
blkdev_iomap_begin rounds down the offset to the logical block size
before stashing it in iomap-&gt;offset and checking that it still is
inside the inode size.
Check the i_size check to the raw pos value so that we don't try a
zero size write if iter-&gt;pos is unaligned.
CVE-2024-38584:In the Linux kernel, the following vulnerability has been resolved:
net: ti: icssg_prueth: Fix NULL pointer dereference in prueth_probe()
In the prueth_probe() function, if one of the calls to emac_phy_connect()
fails due to of_phy_connect() returning NULL, then the subsequent call to
phy_attached_info() will dereference a NULL pointer.
Check the return code of emac_phy_connect and fail cleanly if there is an
error.
CVE-2024-38616:In the Linux kernel, the following vulnerability has been resolved:
wifi: carl9170: re-fix fortified-memset warning
The carl9170_tx_release() function sometimes triggers a fortified-memset
warning in my randconfig builds:
In file included from include/linux/string.h:254,
                 from drivers/net/wireless/ath/carl9170/tx.c:40:
In function 'fortify_memset_chk',
    inlined from 'carl9170_tx_release' at drivers/net/wireless/ath/carl9170/tx.c:283:2,
    inlined from 'kref_put' at include/linux/kref.h:65:3,
    inlined from 'carl9170_tx_put_skb' at drivers/net/wireless/ath/carl9170/tx.c:342:9:
include/linux/fortify-string.h:493:25: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
  493 |                         __write_overflow_field(p_size_field, size);
Kees previously tried to avoid this by using memset_after(), but it seems
this does not fully address the problem. I noticed that the memset_after()
here is done on a different part of the union (status) than the original
cast was from (rate_driver_data), which may confuse the compiler.
Unfortunately, the memset_after() trick does not work on driver_rates[]
because that is part of an anonymous struct, and I could not get
struct_group() to do this either. Using two separate memset() calls
on the two members does address the warning though.
CVE-2021-47610:In the Linux kernel, the following vulnerability has been resolved:
drm/msm: Fix null ptr access msm_ioctl_gem_submit()
Fix the below null pointer dereference in msm_ioctl_gem_submit():
 26545.260705:   Call trace:
 26545.263223:    kref_put+0x1c/0x60
 26545.266452:    msm_ioctl_gem_submit+0x254/0x744
 26545.270937:    drm_ioctl_kernel+0xa8/0x124
 26545.274976:    drm_ioctl+0x21c/0x33c
 26545.278478:    drm_compat_ioctl+0xdc/0xf0
 26545.282428:    __arm64_compat_sys_ioctl+0xc8/0x100
 26545.287169:    el0_svc_common+0xf8/0x250
 26545.291025:    do_el0_svc_compat+0x28/0x54
 26545.295066:    el0_svc_compat+0x10/0x1c
 26545.298838:    el0_sync_compat_handler+0xa8/0xcc
 26545.303403:    el0_sync_compat+0x188/0x1c0
 26545.307445:   Code: d503201f d503201f 52800028 4b0803e8 (b8680008)
 26545.318799:   Kernel panic - not syncing: Oops: Fatal exception
CVE-2023-52883:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix possible null pointer dereference
abo-&gt;tbo.resource may be NULL in amdgpu_vm_bo_update.
CVE-2024-38622:In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dpu: Add callback function pointer check before its call
In dpu_core_irq_callback_handler() callback function pointer is compared to NULL,
but then callback function is unconditionally called by this pointer.
Fix this bug by adding conditional return.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Patchwork: https://patchwork.freedesktop.org/patch/588237/
CVE-2024-38664:In the Linux kernel, the following vulnerability has been resolved:
drm: zynqmp_dpsub: Always register bridge
We must always register the DRM bridge, since zynqmp_dp_hpd_work_func
calls drm_bridge_hpd_notify, which in turn expects hpd_mutex to be
initialized. We do this before zynqmp_dpsub_drm_init since that calls
drm_bridge_attach. This fixes the following lockdep warning:
[   19.217084] ------------[ cut here ]------------
[   19.227530] DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)
[   19.227768] WARNING: CPU: 0 PID: 140 at kernel/locking/mutex.c:582 __mutex_lock+0x4bc/0x550
[   19.241696] Modules linked in:
[   19.244937] CPU: 0 PID: 140 Comm: kworker/0:4 Not tainted 6.6.20+ #96
[   19.252046] Hardware name: xlnx,zynqmp (DT)
[   19.256421] Workqueue: events zynqmp_dp_hpd_work_func
[   19.261795] pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[   19.269104] pc : __mutex_lock+0x4bc/0x550
[   19.273364] lr : __mutex_lock+0x4bc/0x550
[   19.277592] sp : ffffffc085c5bbe0
[   19.281066] x29: ffffffc085c5bbe0 x28: 0000000000000000 x27: ffffff88009417f8
[   19.288624] x26: ffffff8800941788 x25: ffffff8800020008 x24: ffffffc082aa3000
[   19.296227] x23: ffffffc080d90e3c x22: 0000000000000002 x21: 0000000000000000
[   19.303744] x20: 0000000000000000 x19: ffffff88002f5210 x18: 0000000000000000
[   19.311295] x17: 6c707369642e3030 x16: 3030613464662072 x15: 0720072007200720
[   19.318922] x14: 0000000000000000 x13: 284e4f5f4e524157 x12: 0000000000000001
[   19.326442] x11: 0001ffc085c5b940 x10: 0001ff88003f388b x9 : 0001ff88003f3888
[   19.334003] x8 : 0001ff88003f3888 x7 : 0000000000000000 x6 : 0000000000000000
[   19.341537] x5 : 0000000000000000 x4 : 0000000000001668 x3 : 0000000000000000
[   19.349054] x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffffff88003f3880
[   19.356581] Call trace:
[   19.359160]  __mutex_lock+0x4bc/0x550
[   19.363032]  mutex_lock_nested+0x24/0x30
[   19.367187]  drm_bridge_hpd_notify+0x2c/0x6c
[   19.371698]  zynqmp_dp_hpd_work_func+0x44/0x54
[   19.376364]  process_one_work+0x3ac/0x988
[   19.380660]  worker_thread+0x398/0x694
[   19.384736]  kthread+0x1bc/0x1c0
[   19.388241]  ret_from_fork+0x10/0x20
[   19.392031] irq event stamp: 183
[   19.395450] hardirqs last  enabled at (183): [&lt;ffffffc0800b9278&gt;] finish_task_switch.isra.0+0xa8/0x2d4
[   19.405140] hardirqs last disabled at (182): [&lt;ffffffc081ad3754&gt;] __schedule+0x714/0xd04
[   19.413612] softirqs last  enabled at (114): [&lt;ffffffc080133de8&gt;] srcu_invoke_callbacks+0x158/0x23c
[   19.423128] softirqs last disabled at (110): [&lt;ffffffc080133de8&gt;] srcu_invoke_callbacks+0x158/0x23c
[   19.432614] ---[ end trace 0000000000000000 ]---
(cherry picked from commit 61ba791c4a7a09a370c45b70a81b8c7d4cf6b2ae)
CVE-2024-39371:In the Linux kernel, the following vulnerability has been resolved:
io_uring: check for non-NULL file pointer in io_file_can_poll()
In earlier kernels, it was possible to trigger a NULL pointer
dereference off the forced async preparation path, if no file had
been assigned. The trace leading to that looks as follows:
BUG: kernel NULL pointer dereference, address: 00000000000000b0
PGD 0 P4D 0
Oops: 0000 [#1] PREEMPT SMP
CPU: 67 PID: 1633 Comm: buf-ring-invali Not tainted 6.8.0-rc3+ #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS unknown 2/2/2022
RIP: 0010:io_buffer_select+0xc3/0x210
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
RSP: 0018:ffffb7bec38c7d88 EFLAGS: 00010246
RAX: ffff97af2be61000 RBX: ffff97af234f1700 RCX: 0000000000000040
RDX: 0000000000000000 RSI: ffff97aecfb04820 RDI: ffff97af234f1700
RBP: 0000000000000000 R08: 0000000000200030 R09: 0000000000000020
R10: ffffb7bec38c7dc8 R11: 000000000000c000 R12: ffffb7bec38c7db8
R13: ffff97aecfb05800 R14: ffff97aecfb05800 R15: ffff97af2be5e000
FS:  00007f852f74b740(0000) GS:ffff97b1eeec0000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00000000000000b0 CR3: 000000016deab005 CR4: 0000000000370ef0
Call Trace:
 &lt;TASK&gt;
 ? __die+0x1f/0x60
 ? page_fault_oops+0x14d/0x420
 ? do_user_addr_fault+0x61/0x6a0
 ? exc_page_fault+0x6c/0x150
 ? asm_exc_page_fault+0x22/0x30
 ? io_buffer_select+0xc3/0x210
 __io_import_iovec+0xb5/0x120
 io_readv_prep_async+0x36/0x70
 io_queue_sqe_fallback+0x20/0x260
 io_submit_sqes+0x314/0x630
 __do_sys_io_uring_enter+0x339/0xbc0
 ? __do_sys_io_uring_register+0x11b/0xc50
 ? vm_mmap_pgoff+0xce/0x160
 do_syscall_64+0x5f/0x180
 entry_SYSCALL_64_after_hwframe+0x46/0x4e
RIP: 0033:0x55e0a110a67e
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
because the request is marked forced ASYNC and has a bad file fd, and
hence takes the forced async prep path.
Current kernels with the request async prep cleaned up can no longer hit
this issue, but for ease of backporting, let's add this safety check in
here too as it really doesn't hurt. For both cases, this will inevitably
end with a CQE posted with -EBADF.
CVE-2024-39468:In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix deadlock in smb2_find_smb_tcon()
Unlock cifs_tcp_ses_lock before calling cifs_put_smb_ses() to avoid such
deadlock.
CVE-2021-47583:In the Linux kernel, the following vulnerability has been resolved:
media: mxl111sf: change mutex_init() location
Syzbot reported, that mxl111sf_ctrl_msg() uses uninitialized
mutex. The problem was in wrong mutex_init() location.
Previous mutex_init(&amp;state-&gt;msg_lock) call was in -&gt;init() function, but
dvb_usbv2_init() has this order of calls:
	dvb_usbv2_init()
	  dvb_usbv2_adapter_init()
	    dvb_usbv2_adapter_frontend_init()
	      props-&gt;frontend_attach()
	  props-&gt;init()
Since mxl111sf_* devices call mxl111sf_ctrl_msg() in -&gt;frontend_attach()
internally we need to initialize state-&gt;msg_lock before
frontend_attach(). To achieve it, -&gt;probe() call added to all mxl111sf_*
devices, which will simply initiaize mutex.
CVE-2022-48743:In the Linux kernel, the following vulnerability has been resolved:
net: amd-xgbe: Fix skb data length underflow
There will be BUG_ON() triggered in include/linux/skbuff.h leading to
intermittent kernel panic, when the skb length underflow is detected.
Fix this by dropping the packet if such length underflows are seen
because of inconsistencies in the hardware descriptors.
CVE-2024-35885:In the Linux kernel, the following vulnerability has been resolved:
mlxbf_gige: stop interface during shutdown
The mlxbf_gige driver intermittantly encounters a NULL pointer
exception while the system is shutting down via &quot;reboot&quot; command.
The mlxbf_driver will experience an exception right after executing
its shutdown() method.  One example of this exception is:
Unable to handle kernel NULL pointer dereference at virtual address 0000000000000070
Mem abort info:
  ESR = 0x0000000096000004
  EC = 0x25: DABT (current EL), IL = 32 bits
  SET = 0, FnV = 0
  EA = 0, S1PTW = 0
  FSC = 0x04: level 0 translation fault
Data abort info:
  ISV = 0, ISS = 0x00000004
  CM = 0, WnR = 0
user pgtable: 4k pages, 48-bit VAs, pgdp=000000011d373000
[0000000000000070] pgd=0000000000000000, p4d=0000000000000000
Internal error: Oops: 96000004 [#1] SMP
CPU: 0 PID: 13 Comm: ksoftirqd/0 Tainted: G S         OE     5.15.0-bf.6.gef6992a #1
Hardware name: https://www.mellanox.com BlueField SoC/BlueField SoC, BIOS 4.0.2.12669 Apr 21 2023
pstate: 20400009 (nzCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
pc : mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]
lr : mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]
sp : ffff8000080d3c10
x29: ffff8000080d3c10 x28: ffffcce72cbb7000 x27: ffff8000080d3d58
x26: ffff0000814e7340 x25: ffff331cd1a05000 x24: ffffcce72c4ea008
x23: ffff0000814e4b40 x22: ffff0000814e4d10 x21: ffff0000814e4128
x20: 0000000000000000 x19: ffff0000814e4a80 x18: ffffffffffffffff
x17: 000000000000001c x16: ffffcce72b4553f4 x15: ffff80008805b8a7
x14: 0000000000000000 x13: 0000000000000030 x12: 0101010101010101
x11: 7f7f7f7f7f7f7f7f x10: c2ac898b17576267 x9 : ffffcce720fa5404
x8 : ffff000080812138 x7 : 0000000000002e9a x6 : 0000000000000080
x5 : ffff00008de3b000 x4 : 0000000000000000 x3 : 0000000000000001
x2 : 0000000000000000 x1 : 0000000000000000 x0 : 0000000000000000
Call trace:
 mlxbf_gige_handle_tx_complete+0xc8/0x170 [mlxbf_gige]
 mlxbf_gige_poll+0x54/0x160 [mlxbf_gige]
 __napi_poll+0x40/0x1c8
 net_rx_action+0x314/0x3a0
 __do_softirq+0x128/0x334
 run_ksoftirqd+0x54/0x6c
 smpboot_thread_fn+0x14c/0x190
 kthread+0x10c/0x110
 ret_from_fork+0x10/0x20
Code: 8b070000 f9000ea0 f95056c0 f86178a1 (b9407002)
---[ end trace 7cc3941aa0d8e6a4 ]---
Kernel panic - not syncing: Oops: Fatal exception in interrupt
Kernel Offset: 0x4ce722520000 from 0xffff800008000000
PHYS_OFFSET: 0x80000000
CPU features: 0x000005c1,a3330e5a
Memory Limit: none
---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
During system shutdown, the mlxbf_gige driver's shutdown() is always executed.
However, the driver's stop() method will only execute if networking interface
configuration logic within the Linux distribution has been setup to do so.
If shutdown() executes but stop() does not execute, NAPI remains enabled
and this can lead to an exception if NAPI is scheduled while the hardware
interface has only been partially deinitialized.
The networking interface managed by the mlxbf_gige driver must be properly
stopped during system shutdown so that IFF_UP is cleared, the hardware
interface is put into a clean state, and NAPI is fully deinitialized.
CVE-2024-35912:In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: rfi: fix potential response leaks
If the rx payload length check fails, or if kmemdup() fails,
we still need to free the command response. Fix that.
CVE-2024-35911:In the Linux kernel, the following vulnerability has been resolved:
ice: fix memory corruption bug with suspend and rebuild
The ice driver would previously panic after suspend. This is caused
from the driver *only* calling the ice_vsi_free_q_vectors() function by
itself, when it is suspending. Since commit b3e7b3a6ee92 (&quot;ice: prevent
NULL pointer deref during reload&quot;) the driver has zeroed out
num_q_vectors, and only restored it in ice_vsi_cfg_def().
This further causes the ice_rebuild() function to allocate a zero length
buffer, after which num_q_vectors is updated, and then the new value of
num_q_vectors is used to index into the zero length buffer, which
corrupts memory.
The fix entails making sure all the code referencing num_q_vectors only
does so after it has been reset via ice_vsi_cfg_def().
I didn't perform a full bisect, but I was able to test against 6.1.77
kernel and that ice driver works fine for suspend/resume with no panic,
so sometime since then, this problem was introduced.
Also clean up an un-needed init of a local variable in the function
being modified.
PANIC from 6.8.0-rc1:
[1026674.915596] PM: suspend exit
[1026675.664697] ice 0000:17:00.1: PTP reset successful
[1026675.664707] ice 0000:17:00.1: 2755 msecs passed between update to cached PHC time
[1026675.667660] ice 0000:b1:00.0: PTP reset successful
[1026675.675944] ice 0000:b1:00.0: 2832 msecs passed between update to cached PHC time
[1026677.137733] ixgbe 0000:31:00.0 ens787: NIC Link is Up 1 Gbps, Flow Control: None
[1026677.190201] BUG: kernel NULL pointer dereference, address: 0000000000000010
[1026677.192753] ice 0000:17:00.0: PTP reset successful
[1026677.192764] ice 0000:17:00.0: 4548 msecs passed between update to cached PHC time
[1026677.197928] #PF: supervisor read access in kernel mode
[1026677.197933] #PF: error_code(0x0000) - not-present page
[1026677.197937] PGD 1557a7067 P4D 0
[1026677.212133] ice 0000:b1:00.1: PTP reset successful
[1026677.212143] ice 0000:b1:00.1: 4344 msecs passed between update to cached PHC time
[1026677.212575]
[1026677.243142] Oops: 0000 [#1] PREEMPT SMP NOPTI
[1026677.247918] CPU: 23 PID: 42790 Comm: kworker/23:0 Kdump: loaded Tainted: G        W          6.8.0-rc1+ #1
[1026677.257989] Hardware name: Intel Corporation M50CYP2SBSTD/M50CYP2SBSTD, BIOS SE5C620.86B.01.01.0005.2202160810 02/16/2022
[1026677.269367] Workqueue: ice ice_service_task [ice]
[1026677.274592] RIP: 0010:ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]
[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
[1026677.300877] RSP: 0018:ff3be62a6399bcc0 EFLAGS: 00010202
[1026677.306556] RAX: ff28691e28980828 RBX: ff28691e41099828 RCX: 0000000000188000
[1026677.314148] RDX: 0000000000000000 RSI: 0000000000000010 RDI: ff28691e41099828
[1026677.321730] RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
[1026677.329311] R10: 0000000000000007 R11: ffffffffffffffc0 R12: 0000000000000010
[1026677.336896] R13: 0000000000000000 R14: 0000000000000000 R15: ff28691e0eaa81a0
[1026677.344472] FS:  0000000000000000(0000) GS:ff28693cbffc0000(0000) knlGS:0000000000000000
[1026677.353000] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[1026677.359195] CR2: 0000000000000010 CR3: 0000000128df4001 CR4: 0000000000771ef0
[1026677.366779] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[1026677.374369] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[1026677.381952] PKRU: 55555554
[1026677.385116] Call Trace:
[1026677.388023]  &lt;TASK&gt;
[1026677.390589]  ? __die+0x20/0x70
[1026677.394105]  ? page_fault_oops+0x82/0x160
[1026677.398576]  ? do_user_addr_fault+0x65/0x6a0
[1026677.403307]  ? exc_page_fault+0x6a/0x150
[1026677.407694]  ? asm_exc_page_fault+0x22/0x30
[1026677.412349]  ? ice_vsi_rebuild_set_coalesce+0x130/0x1e0 [ice]
[1026677.4186
---truncated---
CVE-2024-35907:In the Linux kernel, the following vulnerability has been resolved:
mlxbf_gige: call request_irq() after NAPI initialized
The mlxbf_gige driver encounters a NULL pointer exception in
mlxbf_gige_open() when kdump is enabled.  The sequence to reproduce
the exception is as follows:
a) enable kdump
b) trigger kdump via &quot;echo c &gt; /proc/sysrq-trigger&quot;
c) kdump kernel executes
d) kdump kernel loads mlxbf_gige module
e) the mlxbf_gige module runs its open() as the
   the &quot;oob_net0&quot; interface is brought up
f) mlxbf_gige module will experience an exception
   during its open(), something like:
     Unable to handle kernel NULL pointer dereference at virtual address 0000000000000000
     Mem abort info:
       ESR = 0x0000000086000004
       EC = 0x21: IABT (current EL), IL = 32 bits
       SET = 0, FnV = 0
       EA = 0, S1PTW = 0
       FSC = 0x04: level 0 translation fault
     user pgtable: 4k pages, 48-bit VAs, pgdp=00000000e29a4000
     [0000000000000000] pgd=0000000000000000, p4d=0000000000000000
     Internal error: Oops: 0000000086000004 [#1] SMP
     CPU: 0 PID: 812 Comm: NetworkManager Tainted: G           OE     5.15.0-1035-bluefield #37-Ubuntu
     Hardware name: https://www.mellanox.com BlueField-3 SmartNIC Main Card/BlueField-3 SmartNIC Main Card, BIOS 4.6.0.13024 Jan 19 2024
     pstate: 80400009 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
     pc : 0x0
     lr : __napi_poll+0x40/0x230
     sp : ffff800008003e00
     x29: ffff800008003e00 x28: 0000000000000000 x27: 00000000ffffffff
     x26: ffff000066027238 x25: ffff00007cedec00 x24: ffff800008003ec8
     x23: 000000000000012c x22: ffff800008003eb7 x21: 0000000000000000
     x20: 0000000000000001 x19: ffff000066027238 x18: 0000000000000000
     x17: ffff578fcb450000 x16: ffffa870b083c7c0 x15: 0000aaab010441d0
     x14: 0000000000000001 x13: 00726f7272655f65 x12: 6769675f6662786c
     x11: 0000000000000000 x10: 0000000000000000 x9 : ffffa870b0842398
     x8 : 0000000000000004 x7 : fe5a48b9069706ea x6 : 17fdb11fc84ae0d2
     x5 : d94a82549d594f35 x4 : 0000000000000000 x3 : 0000000000400100
     x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff000066027238
     Call trace:
      0x0
      net_rx_action+0x178/0x360
      __do_softirq+0x15c/0x428
      __irq_exit_rcu+0xac/0xec
      irq_exit+0x18/0x2c
      handle_domain_irq+0x6c/0xa0
      gic_handle_irq+0xec/0x1b0
      call_on_irq_stack+0x20/0x2c
      do_interrupt_handler+0x5c/0x70
      el1_interrupt+0x30/0x50
      el1h_64_irq_handler+0x18/0x2c
      el1h_64_irq+0x7c/0x80
      __setup_irq+0x4c0/0x950
      request_threaded_irq+0xf4/0x1bc
      mlxbf_gige_request_irqs+0x68/0x110 [mlxbf_gige]
      mlxbf_gige_open+0x5c/0x170 [mlxbf_gige]
      __dev_open+0x100/0x220
      __dev_change_flags+0x16c/0x1f0
      dev_change_flags+0x2c/0x70
      do_setlink+0x220/0xa40
      __rtnl_newlink+0x56c/0x8a0
      rtnl_newlink+0x58/0x84
      rtnetlink_rcv_msg+0x138/0x3c4
      netlink_rcv_skb+0x64/0x130
      rtnetlink_rcv+0x20/0x30
      netlink_unicast+0x2ec/0x360
      netlink_sendmsg+0x278/0x490
      __sock_sendmsg+0x5c/0x6c
      ____sys_sendmsg+0x290/0x2d4
      ___sys_sendmsg+0x84/0xd0
      __sys_sendmsg+0x70/0xd0
      __arm64_sys_sendmsg+0x2c/0x40
      invoke_syscall+0x78/0x100
      el0_svc_common.constprop.0+0x54/0x184
      do_el0_svc+0x30/0xac
      el0_svc+0x48/0x160
      el0t_64_sync_handler+0xa4/0x12c
      el0t_64_sync+0x1a4/0x1a8
     Code: bad PC value
     ---[ end trace 7d1c3f3bf9d81885 ]---
     Kernel panic - not syncing: Oops: Fatal exception in interrupt
     Kernel Offset: 0x2870a7a00000 from 0xffff800008000000
     PHYS_OFFSET: 0x80000000
     CPU features: 0x0,000005c1,a3332a5a
     Memory Limit: none
     ---[ end Kernel panic - not syncing: Oops: Fatal exception in interrupt ]---
The exception happens because there is a pending RX interrupt before the
call to request_irq(RX IRQ) executes.  Then, the RX IRQ handler fires
immediately after this request_irq() completes. The
---truncated---
CVE-2024-35920:In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: adding lock to protect decoder context list
Add a lock for the ctx_list, to avoid accessing a NULL pointer
within the 'vpu_dec_ipi_handler' function when the ctx_list has
been deleted due to an unexpected behavior on the SCP IP block.
Hardware name: Google juniper sku16 board (DT)
pstate: 20400005 (nzCv daif +PAN -UAO -TCO BTYPE=--)
pc : vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec]
lr : scp_ipi_handler+0xd0/0x194 [mtk_scp]
sp : ffffffc0131dbbd0
x29: ffffffc0131dbbd0 x28: 0000000000000000
x27: ffffff9bb277f348 x26: ffffff9bb242ad00
x25: ffffffd2d440d3b8 x24: ffffffd2a13ff1d4
x23: ffffff9bb7fe85a0 x22: ffffffc0133fbdb0
x21: 0000000000000010 x20: ffffff9b050ea328
x19: ffffffc0131dbc08 x18: 0000000000001000
x17: 0000000000000000 x16: ffffffd2d461c6e0
x15: 0000000000000242 x14: 000000000000018f
x13: 000000000000004d x12: 0000000000000000
x11: 0000000000000001 x10: fffffffffffffff0
x9 : ffffff9bb6e793a8 x8 : 0000000000000000
x7 : 0000000000000000 x6 : 000000000000003f
x5 : 0000000000000040 x4 : fffffffffffffff0
x3 : 0000000000000020 x2 : ffffff9bb6e79080
x1 : 0000000000000010 x0 : ffffffc0131dbc08
Call trace:
vpu_dec_ipi_handler+0x58/0x1f8 [mtk_vcodec_dec (HASH:6c3f 2)]
scp_ipi_handler+0xd0/0x194 [mtk_scp (HASH:7046 3)]
mt8183_scp_irq_handler+0x44/0x88 [mtk_scp (HASH:7046 3)]
scp_irq_handler+0x48/0x90 [mtk_scp (HASH:7046 3)]
irq_thread_fn+0x38/0x94
irq_thread+0x100/0x1c0
kthread+0x140/0x1fc
ret_from_fork+0x10/0x30
Code: 54000088 f94ca50a eb14015f 54000060 (f9400108)
---[ end trace ace43ce36cbd5c93 ]---
Kernel panic - not syncing: Oops: Fatal exception
SMP: stopping secondary CPUs
Kernel Offset: 0x12c4000000 from 0xffffffc010000000
PHYS_OFFSET: 0xffffffe580000000
CPU features: 0x08240002,2188200c
Memory Limit: none
CVE-2024-35959:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Fix mlx5e_priv_init() cleanup flow
When mlx5e_priv_init() fails, the cleanup flow calls mlx5e_selq_cleanup which
calls mlx5e_selq_apply() that assures that the `priv-&gt;state_lock` is held using
lockdep_is_held().
Acquire the state_lock in mlx5e_selq_cleanup().
Kernel log:
=============================
WARNING: suspicious RCU usage
6.8.0-rc3_net_next_841a9b5 #1 Not tainted
-----------------------------
drivers/net/ethernet/mellanox/mlx5/core/en/selq.c:124 suspicious rcu_dereference_protected() usage!
other info that might help us debug this:
rcu_scheduler_active = 2, debug_locks = 1
2 locks held by systemd-modules/293:
 #0: ffffffffa05067b0 (devices_rwsem){++++}-{3:3}, at: ib_register_client+0x109/0x1b0 [ib_core]
 #1: ffff8881096c65c0 (&amp;device-&gt;client_data_rwsem){++++}-{3:3}, at: add_client_context+0x104/0x1c0 [ib_core]
stack backtrace:
CPU: 4 PID: 293 Comm: systemd-modules Not tainted 6.8.0-rc3_net_next_841a9b5 #1
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x8a/0xa0
 lockdep_rcu_suspicious+0x154/0x1a0
 mlx5e_selq_apply+0x94/0xa0 [mlx5_core]
 mlx5e_selq_cleanup+0x3a/0x60 [mlx5_core]
 mlx5e_priv_init+0x2be/0x2f0 [mlx5_core]
 mlx5_rdma_setup_rn+0x7c/0x1a0 [mlx5_core]
 rdma_init_netdev+0x4e/0x80 [ib_core]
 ? mlx5_rdma_netdev_free+0x70/0x70 [mlx5_core]
 ipoib_intf_init+0x64/0x550 [ib_ipoib]
 ipoib_intf_alloc+0x4e/0xc0 [ib_ipoib]
 ipoib_add_one+0xb0/0x360 [ib_ipoib]
 add_client_context+0x112/0x1c0 [ib_core]
 ib_register_client+0x166/0x1b0 [ib_core]
 ? 0xffffffffa0573000
 ipoib_init_module+0xeb/0x1a0 [ib_ipoib]
 do_one_initcall+0x61/0x250
 do_init_module+0x8a/0x270
 init_module_from_file+0x8b/0xd0
 idempotent_init_module+0x17d/0x230
 __x64_sys_finit_module+0x61/0xb0
 do_syscall_64+0x71/0x140
 entry_SYSCALL_64_after_hwframe+0x46/0x4e
 &lt;/TASK&gt;
CVE-2024-35952:In the Linux kernel, the following vulnerability has been resolved:
drm/ast: Fix soft lockup
There is a while-loop in ast_dp_set_on_off() that could lead to
infinite-loop. This is because the register, VGACRI-Dx, checked in
this API is a scratch register actually controlled by a MCU, named
DPMCU, in BMC.
These scratch registers are protected by scu-lock. If suc-lock is not
off, DPMCU can not update these registers and then host will have soft
lockup due to never updated status.
DPMCU is used to control DP and relative registers to handshake with
host's VGA driver. Even the most time-consuming task, DP's link
training, is less than 100ms. 200ms should be enough.
CVE-2021-47299:In the Linux kernel, the following vulnerability has been resolved:
xdp, net: Fix use-after-free in bpf_xdp_link_release
The problem occurs between dev_get_by_index() and dev_xdp_attach_link().
At this point, dev_xdp_uninstall() is called. Then xdp link will not be
detached automatically when dev is released. But link-&gt;dev already
points to dev, when xdp link is released, dev will still be accessed,
but dev has been released.
dev_get_by_index()        |
link-&gt;dev = dev           |
                          |      rtnl_lock()
                          |      unregister_netdevice_many()
                          |          dev_xdp_uninstall()
                          |      rtnl_unlock()
rtnl_lock();              |
dev_xdp_attach_link()     |
rtnl_unlock();            |
                          |      netdev_run_todo() // dev released
bpf_xdp_link_release()    |
    /* access dev.        |
       use-after-free */  |
[   45.966867] BUG: KASAN: use-after-free in bpf_xdp_link_release+0x3b8/0x3d0
[   45.967619] Read of size 8 at addr ffff00000f9980c8 by task a.out/732
[   45.968297]
[   45.968502] CPU: 1 PID: 732 Comm: a.out Not tainted 5.13.0+ #22
[   45.969222] Hardware name: linux,dummy-virt (DT)
[   45.969795] Call trace:
[   45.970106]  dump_backtrace+0x0/0x4c8
[   45.970564]  show_stack+0x30/0x40
[   45.970981]  dump_stack_lvl+0x120/0x18c
[   45.971470]  print_address_description.constprop.0+0x74/0x30c
[   45.972182]  kasan_report+0x1e8/0x200
[   45.972659]  __asan_report_load8_noabort+0x2c/0x50
[   45.973273]  bpf_xdp_link_release+0x3b8/0x3d0
[   45.973834]  bpf_link_free+0xd0/0x188
[   45.974315]  bpf_link_put+0x1d0/0x218
[   45.974790]  bpf_link_release+0x3c/0x58
[   45.975291]  __fput+0x20c/0x7e8
[   45.975706]  ____fput+0x24/0x30
[   45.976117]  task_work_run+0x104/0x258
[   45.976609]  do_notify_resume+0x894/0xaf8
[   45.977121]  work_pending+0xc/0x328
[   45.977575]
[   45.977775] The buggy address belongs to the page:
[   45.978369] page:fffffc00003e6600 refcount:0 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x4f998
[   45.979522] flags: 0x7fffe0000000000(node=0|zone=0|lastcpupid=0x3ffff)
[   45.980349] raw: 07fffe0000000000 fffffc00003e6708 ffff0000dac3c010 0000000000000000
[   45.981309] raw: 0000000000000000 0000000000000000 00000000ffffffff 0000000000000000
[   45.982259] page dumped because: kasan: bad access detected
[   45.982948]
[   45.983153] Memory state around the buggy address:
[   45.983753]  ffff00000f997f80: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc
[   45.984645]  ffff00000f998000: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   45.985533] &gt;ffff00000f998080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   45.986419]                                               ^
[   45.987112]  ffff00000f998100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   45.988006]  ffff00000f998180: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
[   45.988895] ==================================================================
[   45.989773] Disabling lock debugging due to kernel taint
[   45.990552] Kernel panic - not syncing: panic_on_warn set ...
[   45.991166] CPU: 1 PID: 732 Comm: a.out Tainted: G    B             5.13.0+ #22
[   45.991929] Hardware name: linux,dummy-virt (DT)
[   45.992448] Call trace:
[   45.992753]  dump_backtrace+0x0/0x4c8
[   45.993208]  show_stack+0x30/0x40
[   45.993627]  dump_stack_lvl+0x120/0x18c
[   45.994113]  dump_stack+0x1c/0x34
[   45.994530]  panic+0x3a4/0x7d8
[   45.994930]  end_report+0x194/0x198
[   45.995380]  kasan_report+0x134/0x200
[   45.995850]  __asan_report_load8_noabort+0x2c/0x50
[   45.996453]  bpf_xdp_link_release+0x3b8/0x3d0
[   45.997007]  bpf_link_free+0xd0/0x188
[   45.997474]  bpf_link_put+0x1d0/0x218
[   45.997942]  bpf_link_release+0x3c/0x58
[   45.998429]  __fput+0x20c/0x7e8
[   45.998833]  ____fput+0x24/0x30
[   45.999247]  task_work_run+0x104/0x258
[   45.999731]  do_notify_resume+0x894/0xaf8
[   46.000236]  work_pending
---truncated---
CVE-2021-47304:In the Linux kernel, the following vulnerability has been resolved:
tcp: fix tcp_init_transfer() to not reset icsk_ca_initialized
This commit fixes a bug (found by syzkaller) that could cause spurious
double-initializations for congestion control modules, which could cause
memory leaks or other problems for congestion control modules (like CDG)
that allocate memory in their init functions.
The buggy scenario constructed by syzkaller was something like:
(1) create a TCP socket
(2) initiate a TFO connect via sendto()
(3) while socket is in TCP_SYN_SENT, call setsockopt(TCP_CONGESTION),
    which calls:
       tcp_set_congestion_control() -&gt;
         tcp_reinit_congestion_control() -&gt;
           tcp_init_congestion_control()
(4) receive ACK, connection is established, call tcp_init_transfer(),
    set icsk_ca_initialized=0 (without first calling cc-&gt;release()),
    call tcp_init_congestion_control() again.
Note that in this sequence tcp_init_congestion_control() is called
twice without a cc-&gt;release() call in between. Thus, for CC modules
that allocate memory in their init() function, e.g, CDG, a memory leak
may occur. The syzkaller tool managed to find a reproducer that
triggered such a leak in CDG.
The bug was introduced when that commit 8919a9b31eb4 (&quot;tcp: Only init
congestion control if not initialized already&quot;)
introduced icsk_ca_initialized and set icsk_ca_initialized to 0 in
tcp_init_transfer(), missing the possibility for a sequence like the
one above, where a process could call setsockopt(TCP_CONGESTION) in
state TCP_SYN_SENT (i.e. after the connect() or TFO open sendmsg()),
which would call tcp_init_congestion_control(). It did not intend to
reset any initialization that the user had already explicitly made;
it just missed the possibility of that particular sequence (which
syzkaller managed to find).
CVE-2021-47364:In the Linux kernel, the following vulnerability has been resolved:
comedi: Fix memory leak in compat_insnlist()
`compat_insnlist()` handles the 32-bit version of the `COMEDI_INSNLIST`
ioctl (whenwhen `CONFIG_COMPAT` is enabled).  It allocates memory to
temporarily hold an array of `struct comedi_insn` converted from the
32-bit version in user space.  This memory is only being freed if there
is a fault while filling the array, otherwise it is leaked.
Add a call to `kfree()` to fix the leak.
CVE-2021-47464:In the Linux kernel, the following vulnerability has been resolved:
audit: fix possible null-pointer dereference in audit_filter_rules
Fix  possible null-pointer dereference in audit_filter_rules.
audit_filter_rules() error: we previously assumed 'ctx' could be null
CVE-2021-47517:In the Linux kernel, the following vulnerability has been resolved:
ethtool: do not perform operations on net devices being unregistered
There is a short period between a net device starts to be unregistered
and when it is actually gone. In that time frame ethtool operations
could still be performed, which might end up in unwanted or undefined
behaviours[1].
Do not allow ethtool operations after a net device starts its
unregistration. This patch targets the netlink part as the ioctl one
isn't affected: the reference to the net device is taken and the
operation is executed within an rtnl lock section and the net device
won't be found after unregister.
[1] For example adding Tx queues after unregister ends up in NULL
    pointer exceptions and UaFs, such as:
      BUG: KASAN: use-after-free in kobject_get+0x14/0x90
      Read of size 1 at addr ffff88801961248c by task ethtool/755
      CPU: 0 PID: 755 Comm: ethtool Not tainted 5.15.0-rc6+ #778
      Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.14.0-4.fc34 04/014
      Call Trace:
       dump_stack_lvl+0x57/0x72
       print_address_description.constprop.0+0x1f/0x140
       kasan_report.cold+0x7f/0x11b
       kobject_get+0x14/0x90
       kobject_add_internal+0x3d1/0x450
       kobject_init_and_add+0xba/0xf0
       netdev_queue_update_kobjects+0xcf/0x200
       netif_set_real_num_tx_queues+0xb4/0x310
       veth_set_channels+0x1c3/0x550
       ethnl_set_channels+0x524/0x610
CVE-2021-47519:In the Linux kernel, the following vulnerability has been resolved:
can: m_can: m_can_read_fifo: fix memory leak in error branch
In m_can_read_fifo(), if the second call to m_can_fifo_read() fails,
the function jump to the out_fail label and returns without calling
m_can_receive_skb(). This means that the skb previously allocated by
alloc_can_skb() is not freed. In other terms, this is a memory leak.
This patch adds a goto label to destroy the skb if an error occurs.
Issue was found with GCC -fanalyzer, please follow the link below for
details.
CVE-2021-47570:In the Linux kernel, the following vulnerability has been resolved:
staging: r8188eu: fix a memory leak in rtw_wx_read32()
Free &quot;ptmp&quot; before returning -EINVAL.
CVE-2021-47536:In the Linux kernel, the following vulnerability has been resolved:
net/smc: fix wrong list_del in smc_lgr_cleanup_early
smc_lgr_cleanup_early() meant to delete the link
group from the link group list, but it deleted
the list head by mistake.
This may cause memory corruption since we didn't
remove the real link group from the list and later
memseted the link group structure.
We got a list corruption panic when testing:
[  231.277259] list_del corruption. prev-&gt;next should be ffff8881398a8000, but was 0000000000000000
[  231.278222] ------------[ cut here ]------------
[  231.278726] kernel BUG at lib/list_debug.c:53!
[  231.279326] invalid opcode: 0000 [#1] SMP NOPTI
[  231.279803] CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.46+ #435
[  231.280466] Hardware name: Alibaba Cloud ECS, BIOS 8c24b4c 04/01/2014
[  231.281248] Workqueue: events smc_link_down_work
[  231.281732] RIP: 0010:__list_del_entry_valid+0x70/0x90
[  231.282258] Code: 4c 60 82 e8 7d cc 6a 00 0f 0b 48 89 fe 48 c7 c7 88 4c
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;
0b 48 89 fe 48 c7 c7 00 4d 60 82 e8 4a cc 6a 00 0f 0b cc cc cc
[  231.284146] RSP: 0018:ffffc90000033d58 EFLAGS: 00010292
[  231.284685] RAX: 0000000000000054 RBX: ffff8881398a8000 RCX: 0000000000000000
[  231.285415] RDX: 0000000000000001 RSI: ffff88813bc18040 RDI: ffff88813bc18040
[  231.286141] RBP: ffffffff8305ad40 R08: 0000000000000003 R09: 0000000000000001
[  231.286873] R10: ffffffff82803da0 R11: ffffc90000033b90 R12: 0000000000000001
[  231.287606] R13: 0000000000000000 R14: ffff8881398a8000 R15: 0000000000000003
[  231.288337] FS:  0000000000000000(0000) GS:ffff88813bc00000(0000) knlGS:0000000000000000
[  231.289160] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  231.289754] CR2: 0000000000e72058 CR3: 000000010fa96006 CR4: 00000000003706f0
[  231.290485] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  231.291211] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  231.291940] Call Trace:
[  231.292211]  smc_lgr_terminate_sched+0x53/0xa0
[  231.292677]  smc_switch_conns+0x75/0x6b0
[  231.293085]  ? update_load_avg+0x1a6/0x590
[  231.293517]  ? ttwu_do_wakeup+0x17/0x150
[  231.293907]  ? update_load_avg+0x1a6/0x590
[  231.294317]  ? newidle_balance+0xca/0x3d0
[  231.294716]  smcr_link_down+0x50/0x1a0
[  231.295090]  ? __wake_up_common_lock+0x77/0x90
[  231.295534]  smc_link_down_work+0x46/0x60
[  231.295933]  process_one_work+0x18b/0x350
CVE-2024-36026:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fixes a random hang in S4 for SMU v13.0.4/11
While doing multiple S4 stress tests, GC/RLC/PMFW get into
an invalid state resulting into hard hangs.
Adding a GFX reset as workaround just before sending the
MP1_UNLOAD message avoids this failure.
CVE-2024-36882:In the Linux kernel, the following vulnerability has been resolved:
mm: use memalloc_nofs_save() in page_cache_ra_order()
See commit f2c817bed58d (&quot;mm: use memalloc_nofs_save in readahead path&quot;),
ensure that page_cache_ra_order() do not attempt to reclaim file-backed
pages too, or it leads to a deadlock, found issue when test ext4 large
folio.
 INFO: task DataXceiver for:7494 blocked for more than 120 seconds.
 &quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
 task:DataXceiver for state:D stack:0     pid:7494  ppid:1      flags:0x00000200
 Call trace:
  __switch_to+0x14c/0x240
  __schedule+0x82c/0xdd0
  schedule+0x58/0xf0
  io_schedule+0x24/0xa0
  __folio_lock+0x130/0x300
  migrate_pages_batch+0x378/0x918
  migrate_pages+0x350/0x700
  compact_zone+0x63c/0xb38
  compact_zone_order+0xc0/0x118
  try_to_compact_pages+0xb0/0x280
  __alloc_pages_direct_compact+0x98/0x248
  __alloc_pages+0x510/0x1110
  alloc_pages+0x9c/0x130
  folio_alloc+0x20/0x78
  filemap_alloc_folio+0x8c/0x1b0
  page_cache_ra_order+0x174/0x308
  ondemand_readahead+0x1c8/0x2b8
  page_cache_async_ra+0x68/0xb8
  filemap_readahead.isra.0+0x64/0xa8
  filemap_get_pages+0x3fc/0x5b0
  filemap_splice_read+0xf4/0x280
  ext4_file_splice_read+0x2c/0x48 [ext4]
  vfs_splice_read.part.0+0xa8/0x118
  splice_direct_to_actor+0xbc/0x288
  do_splice_direct+0x9c/0x108
  do_sendfile+0x328/0x468
  __arm64_sys_sendfile64+0x8c/0x148
  invoke_syscall+0x4c/0x118
  el0_svc_common.constprop.0+0xc8/0xf0
  do_el0_svc+0x24/0x38
  el0_svc+0x4c/0x1f8
  el0t_64_sync_handler+0xc0/0xc8
  el0t_64_sync+0x188/0x190
CVE-2024-36022:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Init zone device and drm client after mode-1 reset on reload
In passthrough environment, when amdgpu is reloaded after unload, mode-1
is triggered after initializing the necessary IPs, That init does not
include KFD, and KFD init waits until the reset is completed. KFD init
is called in the reset handler, but in this case, the zone device and
drm client is not initialized, causing app to create kernel panic.
v2: Removing the init KFD condition from amdgpu_amdkfd_drm_client_create.
As the previous version has the potential of creating DRM client twice.
v3: v2 patch results in SDMA engine hung as DRM open causes VM clear to SDMA
before SDMA init. Adding the condition to in drm client creation, on top of v1,
to guard against drm client creation call multiple times.
CVE-2024-36033:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: qca: fix info leak when fetching board id
Add the missing sanity check when fetching the board id to avoid leaking
slab data when later requesting the firmware.
CVE-2024-36892:In the Linux kernel, the following vulnerability has been resolved:
mm/slub: avoid zeroing outside-object freepointer for single free
Commit 284f17ac13fe (&quot;mm/slub: handle bulk and single object freeing
separately&quot;) splits single and bulk object freeing in two functions
slab_free() and slab_free_bulk() which leads slab_free() to call
slab_free_hook() directly instead of slab_free_freelist_hook().
If `init_on_free` is set, slab_free_hook() zeroes the object.
Afterward, if `slub_debug=F` and `CONFIG_SLAB_FREELIST_HARDENED` are
set, the do_slab_free() slowpath executes freelist consistency
checks and try to decode a zeroed freepointer which leads to a
&quot;Freepointer corrupt&quot; detection in check_object().
During bulk free, slab_free_freelist_hook() isn't affected as it always
sets it objects freepointer using set_freepointer() to maintain its
reconstructed freelist after `init_on_free`.
For single free, object's freepointer thus needs to be avoided when
stored outside the object if `init_on_free` is set. The freepointer left
as is, check_object() may later detect an invalid pointer value due to
objects overflow.
To reproduce, set `slub_debug=FU init_on_free=1 log_level=7` on the
command line of a kernel build with `CONFIG_SLAB_FREELIST_HARDENED=y`.
dmesg sample log:
[   10.708715] =============================================================================
[   10.710323] BUG kmalloc-rnd-05-32 (Tainted: G    B           T ): Freepointer corrupt
[   10.712695] -----------------------------------------------------------------------------
[   10.712695]
[   10.712695] Slab 0xffffd8bdc400d580 objects=32 used=4 fp=0xffff9d9a80356f80 flags=0x200000000000a00(workingset|slab|node=0|zone=2)
[   10.716698] Object 0xffff9d9a80356600 @offset=1536 fp=0x7ee4f480ce0ecd7c
[   10.716698]
[   10.716698] Bytes b4 ffff9d9a803565f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[   10.720703] Object   ffff9d9a80356600: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[   10.720703] Object   ffff9d9a80356610: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[   10.724696] Padding  ffff9d9a8035666c: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00  ................
[   10.724696] Padding  ffff9d9a8035667c: 00 00 00 00                                      ....
[   10.724696] FIX kmalloc-rnd-05-32: Object at 0xffff9d9a80356600 not freed
CVE-2024-36943:In the Linux kernel, the following vulnerability has been resolved:
fs/proc/task_mmu: fix loss of young/dirty bits during pagemap scan
make_uffd_wp_pte() was previously doing:
  pte = ptep_get(ptep);
  ptep_modify_prot_start(ptep);
  pte = pte_mkuffd_wp(pte);
  ptep_modify_prot_commit(ptep, pte);
But if another thread accessed or dirtied the pte between the first 2
calls, this could lead to loss of that information.  Since
ptep_modify_prot_start() gets and clears atomically, the following is the
correct pattern and prevents any possible race.  Any access after the
first call would see an invalid pte and cause a fault:
  pte = ptep_modify_prot_start(ptep);
  pte = pte_mkuffd_wp(pte);
  ptep_modify_prot_commit(ptep, pte);
CVE-2024-36932:In the Linux kernel, the following vulnerability has been resolved:
thermal/debugfs: Prevent use-after-free from occurring after cdev removal
Since thermal_debug_cdev_remove() does not run under cdev-&gt;lock, it can
run in parallel with thermal_debug_cdev_state_update() and it may free
the struct thermal_debugfs object used by the latter after it has been
checked against NULL.
If that happens, thermal_debug_cdev_state_update() will access memory
that has been freed already causing the kernel to crash.
Address this by using cdev-&gt;lock in thermal_debug_cdev_remove() around
the cdev-&gt;debugfs value check (in case the same cdev is removed at the
same time in two different threads) and its reset to NULL.
Cc :6.8+ &lt;stable@vger.kernel.org&gt; # 6.8+
CVE-2021-4440:In the Linux kernel, the following vulnerability has been resolved:
x86/xen: Drop USERGS_SYSRET64 paravirt call
commit afd30525a659ac0ae0904f0cb4a2ca75522c3123 upstream.
USERGS_SYSRET64 is used to return from a syscall via SYSRET, but
a Xen PV guest will nevertheless use the IRET hypercall, as there
is no sysret PV hypercall defined.
So instead of testing all the prerequisites for doing a sysret and
then mangling the stack for Xen PV again for doing an iret just use
the iret exit from the beginning.
This can easily be done via an ALTERNATIVE like it is done for the
sysenter compat case already.
It should be noted that this drops the optimization in Xen for not
restoring a few registers when returning to user mode, but it seems
as if the saved instructions in the kernel more than compensate for
this drop (a kernel build in a Xen PV guest was slightly faster with
this patch applied).
While at it remove the stale sysret32 remnants.
  [ pawan: Brad Spengler and Salvatore Bonaccorso &lt;carnil@debian.org&gt;
	   reported a problem with the 5.10 backport commit edc702b4a820
	   (&quot;x86/entry_64: Add VERW just before userspace transition&quot;).
	   When CONFIG_PARAVIRT_XXL=y, CLEAR_CPU_BUFFERS is not executed in
	   syscall_return_via_sysret path as USERGS_SYSRET64 is runtime
	   patched to:
	.cpu_usergs_sysret64    = { 0x0f, 0x01, 0xf8,
				    0x48, 0x0f, 0x07 }, // swapgs; sysretq
	   which is missing CLEAR_CPU_BUFFERS. It turns out dropping
	   USERGS_SYSRET64 simplifies the code, allowing CLEAR_CPU_BUFFERS
	   to be explicitly added to syscall_return_via_sysret path. Below
	   is with CONFIG_PARAVIRT_XXL=y and this patch applied:
	   syscall_return_via_sysret:
	   ...
	   &lt;+342&gt;:   swapgs
	   &lt;+345&gt;:   xchg   %ax,%ax
	   &lt;+347&gt;:   verw   -0x1a2(%rip)  &lt;------
	   &lt;+354&gt;:   sysretq
  ]
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.
CVE-2022-48738:In the Linux kernel, the following vulnerability has been resolved:
ASoC: ops: Reject out of bounds values in snd_soc_put_volsw()
We don't currently validate that the values being set are within the range
we advertised to userspace as being valid, do so and reject any values
that are out of range.
CVE-2021-47351:In the Linux kernel, the following vulnerability has been resolved:
ubifs: Fix races between xattr_{set|get} and listxattr operations
UBIFS may occur some problems with concurrent xattr_{set|get} and
listxattr operations, such as assertion failure, memory corruption,
stale xattr value[1].
Fix it by importing a new rw-lock in @ubifs_inode to serilize write
operations on xattr, concurrent read operations are still effective,
just like ext4.
[1] https://lore.kernel.org/linux-mtd/20200630130438.141649-1-houtao1@huawei.com
CVE-2024-36030:In the Linux kernel, the following vulnerability has been resolved:
octeontx2-af: fix the double free in rvu_npc_freemem()
Clang static checker(scan-build) warning：
drivers/net/ethernet/marvell/octeontx2/af/rvu_npc.c:line 2184, column 2
Attempt to free released memory.
npc_mcam_rsrcs_deinit() has released 'mcam-&gt;counters.bmap'. Deleted this
redundant kfree() to fix this double free problem.
CVE-2021-47430:In the Linux kernel, the following vulnerability has been resolved:
x86/entry: Clear X86_FEATURE_SMAP when CONFIG_X86_SMAP=n
Commit
  3c73b81a9164 (&quot;x86/entry, selftests: Further improve user entry sanity checks&quot;)
added a warning if AC is set when in the kernel.
Commit
  662a0221893a3d (&quot;x86/entry: Fix AC assertion&quot;)
changed the warning to only fire if the CPU supports SMAP.
However, the warning can still trigger on a machine that supports SMAP
but where it's disabled in the kernel config and when running the
syscall_nt selftest, for example:
  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 49 at irqentry_enter_from_user_mode
  CPU: 0 PID: 49 Comm: init Tainted: G                T 5.15.0-rc4+ #98 e6202628ee053b4f310759978284bd8bb0ce6905
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
  RIP: 0010:irqentry_enter_from_user_mode
  ...
  Call Trace:
   ? irqentry_enter
   ? exc_general_protection
   ? asm_exc_general_protection
   ? asm_exc_general_protectio
IS_ENABLED(CONFIG_X86_SMAP) could be added to the warning condition, but
even this would not be enough in case SMAP is disabled at boot time with
the &quot;nosmap&quot; parameter.
To be consistent with &quot;nosmap&quot; behaviour, clear X86_FEATURE_SMAP when
!CONFIG_X86_SMAP.
Found using entry-fuzz + satrandconfig.
 [ bp: Massage commit message. ]
CVE-2024-38610:In the Linux kernel, the following vulnerability has been resolved:
drivers/virt/acrn: fix PFNMAP PTE checks in acrn_vm_ram_map()
Patch series &quot;mm: follow_pte() improvements and acrn follow_pte() fixes&quot;.
Patch #1 fixes a bunch of issues I spotted in the acrn driver.  It
compiles, that's all I know.  I'll appreciate some review and testing from
acrn folks.
Patch #2+#3 improve follow_pte(), passing a VMA instead of the MM, adding
more sanity checks, and improving the documentation.  Gave it a quick test
on x86-64 using VM_PAT that ends up using follow_pte().
This patch (of 3):
We currently miss handling various cases, resulting in a dangerous
follow_pte() (previously follow_pfn()) usage.
(1) We're not checking PTE write permissions.
Maybe we should simply always require pte_write() like we do for
pin_user_pages_fast(FOLL_WRITE)? Hard to tell, so let's check for
ACRN_MEM_ACCESS_WRITE for now.
(2) We're not rejecting refcounted pages.
As we are not using MMU notifiers, messing with refcounted pages is
dangerous and can result in use-after-free. Let's make sure to reject them.
(3) We are only looking at the first PTE of a bigger range.
We only lookup a single PTE, but memmap-&gt;len may span a larger area.
Let's loop over all involved PTEs and make sure the PFN range is
actually contiguous. Reject everything else: it couldn't have worked
either way, and rather made use access PFNs we shouldn't be accessing.
CVE-2021-47296:In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Fix kvm_arch_vcpu_ioctl vcpu_load leak
vcpu_put is not called if the user copy fails. This can result in preempt
notifier corruption and crashes, among other issues.
CVE-2024-38580:In the Linux kernel, the following vulnerability has been resolved:
epoll: be better about file lifetimes
epoll can call out to vfs_poll() with a file pointer that may race with
the last 'fput()'. That would make f_count go down to zero, and while
the ep-&gt;mtx locking means that the resulting file pointer tear-down will
be blocked until the poll returns, it means that f_count is already
dead, and any use of it won't actually get a reference to the file any
more: it's dead regardless.
Make sure we have a valid ref on the file pointer before we call down to
vfs_poll() from the epoll routines.
CVE-2022-48760:In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix hang in usb_kill_urb by adding memory barriers
The syzbot fuzzer has identified a bug in which processes hang waiting
for usb_kill_urb() to return.  It turns out the issue is not unlinking
the URB; that works just fine.  Rather, the problem arises when the
wakeup notification that the URB has completed is not received.
The reason is memory-access ordering on SMP systems.  In outline form,
usb_kill_urb() and __usb_hcd_giveback_urb() operating concurrently on
different CPUs perform the following actions:
CPU 0					CPU 1
----------------------------		---------------------------------
usb_kill_urb():				__usb_hcd_giveback_urb():
  ...					  ...
  atomic_inc(&amp;urb-&gt;reject);		  atomic_dec(&amp;urb-&gt;use_count);
  ...					  ...
  wait_event(usb_kill_urb_queue,
	atomic_read(&amp;urb-&gt;use_count) == 0);
					  if (atomic_read(&amp;urb-&gt;reject))
						wake_up(&amp;usb_kill_urb_queue);
Confining your attention to urb-&gt;reject and urb-&gt;use_count, you can
see that the overall pattern of accesses on CPU 0 is:
	write urb-&gt;reject, then read urb-&gt;use_count;
whereas the overall pattern of accesses on CPU 1 is:
	write urb-&gt;use_count, then read urb-&gt;reject.
This pattern is referred to in memory-model circles as SB (for &quot;Store
Buffering&quot;), and it is well known that without suitable enforcement of
the desired order of accesses -- in the form of memory barriers -- it
is entirely possible for one or both CPUs to execute their reads ahead
of their writes.  The end result will be that sometimes CPU 0 sees the
old un-decremented value of urb-&gt;use_count while CPU 1 sees the old
un-incremented value of urb-&gt;reject.  Consequently CPU 0 ends up on
the wait queue and never gets woken up, leading to the observed hang
in usb_kill_urb().
The same pattern of accesses occurs in usb_poison_urb() and the
failure pathway of usb_hcd_submit_urb().
The problem is fixed by adding suitable memory barriers.  To provide
proper memory-access ordering in the SB pattern, a full barrier is
required on both CPUs.  The atomic_inc() and atomic_dec() accesses
themselves don't provide any memory ordering, but since they are
present, we can use the optimized smp_mb__after_atomic() memory
barrier in the various routines to obtain the desired effect.
This patch adds the necessary memory barriers.
CVE-2024-36965:In the Linux kernel, the following vulnerability has been resolved:
remoteproc: mediatek: Make sure IPI buffer fits in L2TCM
The IPI buffer location is read from the firmware that we load to the
System Companion Processor, and it's not granted that both the SRAM
(L2TCM) size that is defined in the devicetree node is large enough
for that, and while this is especially true for multi-core SCP, it's
still useful to check on single-core variants as well.
Failing to perform this check may make this driver perform R/W
operations out of the L2TCM boundary, resulting (at best) in a
kernel panic.
To fix that, check that the IPI buffer fits, otherwise return a
failure and refuse to boot the relevant SCP core (or the SCP at
all, if this is single core).
CVE-2024-38629:In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Avoid unnecessary destruction of file_ida
file_ida is allocated during cdev open and is freed accordingly
during cdev release. This sequence is guaranteed by driver file
operations. Therefore, there is no need to destroy an already empty
file_ida when the WQ cdev is removed.
Worse, ida_free() in cdev release may happen after destruction of
file_ida per WQ cdev. This can lead to accessing an id in file_ida
after it has been destroyed, resulting in a kernel panic.
Remove ida_destroy(&amp;file_ida) to address these issues.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2238</id>
		<title>An update for krb5 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37370" id="CVE-2024-37370" title="CVE-2024-37370" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37371" id="CVE-2024-37371" title="CVE-2024-37371" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2239</id>
		<title>An update for libarchive is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20696" id="CVE-2024-20696" title="CVE-2024-20696" type="cve"/>
		</references>
		<description>CVE-2024-20696:Windows Libarchive Remote Code Execution Vulnerability</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2240</id>
		<title>An update for libndp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5564" id="CVE-2024-5564" title="CVE-2024-5564" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2241</id>
		<title>An update for libva is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39929" id="CVE-2023-39929" title="CVE-2023-39929" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2242</id>
		<title>An update for microcode_ctl is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45733" id="CVE-2023-45733" title="CVE-2023-45733" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45745" id="CVE-2023-45745" title="CVE-2023-45745" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46103" id="CVE-2023-46103" title="CVE-2023-46103" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47855" id="CVE-2023-47855" title="CVE-2023-47855" type="cve"/>
		</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.
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.
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.
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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2243</id>
		<title>An update for mod_http2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36387" id="CVE-2024-36387" title="CVE-2024-36387" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2244</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21176" id="CVE-2024-21176" title="CVE-2024-21176" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2245</id>
		<title>An update for nano is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5742" id="CVE-2024-5742" title="CVE-2024-5742" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
				<package arch="aarch64" epoch="0" name="nano" release="1.fos23" version="8.0">
					<filename>nano-8.0-1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2246</id>
		<title>An update for ntfs-3g is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52890" id="CVE-2023-52890" title="CVE-2023-52890" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2247</id>
		<title>An update for openjpeg2 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39328" id="CVE-2023-39328" title="CVE-2023-39328" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2248</id>
		<title>An update for openssh is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6409" id="CVE-2024-6409" title="CVE-2024-6409" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6387" id="CVE-2024-6387" title="CVE-2024-6387" type="cve"/>
		</references>
		<description>CVE-2024-6409:A race condition vulnerability was discovered in how signals are handled by OpenSSH's server (sshd). If a remote attacker does not authenticate within a set time period, then sshd'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.
CVE-2024-6387:A security regression (CVE-2006-5051) was discovered in OpenSSH'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2249</id>
		<title>An update for openssl is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4741" id="CVE-2024-4741" title="CVE-2024-4741" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5535" id="CVE-2024-5535" title="CVE-2024-5535" type="cve"/>
		</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.
CVE-2024-5535:Issue summary: Calling the OpenSSL API function SSL_select_next_proto with an
empty supported client protocols buffer may cause a crash or memory contents to
be sent to the peer.
Impact summary: A buffer overread can have a range of potential consequences
such as unexpected application beahviour or a crash. In particular this issue
could result in up to 255 bytes of arbitrary private data from memory being sent
to the peer leading to a loss of confidentiality. However, only applications
that directly call the SSL_select_next_proto function with a 0 length list of
supported client protocols are affected by this issue. This would normally never
be a valid scenario and is typically not under attacker control but may occur by
accident in the case of a configuration or programming error in the calling
application.
The OpenSSL API function SSL_select_next_proto is typically used by TLS
applications that support ALPN (Application Layer Protocol Negotiation) or NPN
(Next Protocol Negotiation). NPN is older, was never standardised and
is deprecated in favour of ALPN. We believe that ALPN is significantly more
widely deployed than NPN. The SSL_select_next_proto function accepts a list of
protocols from the server and a list of protocols from the client and returns
the first protocol that appears in the server list that also appears in the
client list. In the case of no overlap between the two lists it returns the
first item in the client list. In either case it will signal whether an overlap
between the two lists was found. In the case where SSL_select_next_proto is
called with a zero length client list it fails to notice this condition and
returns the memory immediately following the client list pointer (and reports
that there was no overlap in the lists).
This function is typically called from a server side application callback for
ALPN or a client side application callback for NPN. In the case of ALPN the list
of protocols supplied by the client is guaranteed by libssl to never be zero in
length. The list of server protocols comes from the application and should never
normally be expected to be of zero length. In this case if the
SSL_select_next_proto function has been called as expected (with the list
supplied by the client passed in the client/client_len parameters), then the
application will not be vulnerable to this issue. If the application has
accidentally been configured with a zero length server list, and has
accidentally passed that zero length server list in the client/client_len
parameters, and has additionally failed to correctly handle a &quot;no overlap&quot;
response (which would normally result in a handshake failure in ALPN) then it
will be vulnerable to this problem.
In the case of NPN, the protocol permits the client to opportunistically select
a protocol when there is no overlap. OpenSSL returns the first client protocol
in the no overlap case in support of this. The list of client protocols comes
from 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 a
client_len of 0 then an invalid memory pointer will be returned instead. If the
application uses this output as the opportunistic protocol then the loss of
confidentiality will occur.
This issue has been assessed as Low severity because applications are most
likely to be vulnerable if they are using NPN instead of ALPN - but NPN is not
widely used. It also requires an application configuration or programming error.
Finally, this issue would not typically be under attacker control making active
exploitation 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 of
OpenSSL at this time. The fix will be included in the next releases when they
become available.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2250</id>
		<title>An update for openvpn is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28882" id="CVE-2024-28882" title="CVE-2024-28882" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27459" id="CVE-2024-27459" title="CVE-2024-27459" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27903" id="CVE-2024-27903" title="CVE-2024-27903" type="cve"/>
		</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
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.
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.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2251</id>
		<title>An update for p7zip is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52169" id="CVE-2023-52169" title="CVE-2023-52169" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52168" id="CVE-2023-52168" title="CVE-2023-52168" type="cve"/>
		</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.
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>FusionOS</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>
				</package>
				<package arch="aarch64" epoch="0" name="p7zip" release="4.fos23" version="16.02">
					<filename>p7zip-16.02-4.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2252</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5458" id="CVE-2024-5458" title="CVE-2024-5458" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4577" id="CVE-2024-4577" title="CVE-2024-4577" type="cve"/>
		</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.
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 &quot;Best-Fit&quot; 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2253</id>
		<title>An update for podman is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32149" id="CVE-2022-32149" title="CVE-2022-32149" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2254</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6239" id="CVE-2024-6239" title="CVE-2024-6239" type="cve"/>
		</references>
		<description>CVE-2024-6239:A flaw was found in the Poppler'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2255</id>
		<title>An update for python-aiosmtpd is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34083" id="CVE-2024-34083" title="CVE-2024-34083" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5206" id="CVE-2024-5206" title="CVE-2024-5206" type="cve"/>
		</references>
		<description>CVE-2024-5206:A sensitive data leakage vulnerability was identified in scikit-learn'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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2257</id>
		<title>An update for python-setuptools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6345" id="CVE-2024-6345" title="CVE-2024-6345" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2258</id>
		<title>An update for python-urllib3 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37891" id="CVE-2024-37891" title="CVE-2024-37891" type="cve"/>
		</references>
		<description>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.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2259</id>
		<title>An update for python-zipp is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5569" id="CVE-2024-5569" title="CVE-2024-5569" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2260</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4467" id="CVE-2024-4467" title="CVE-2024-4467" type="cve"/>
		</references>
		<description>CVE-2024-4467:A flaw was found in the QEMU disk image utility (qemu-img) 'info' 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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2261</id>
		<title>An update for qt is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39936" id="CVE-2024-39936" title="CVE-2024-39936" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2262</id>
		<title>An update for qt5 is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39936" id="CVE-2024-39936" title="CVE-2024-39936" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2263</id>
		<title>An update for qt5-qtbase is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39936" id="CVE-2024-39936" title="CVE-2024-39936" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2264</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35221" id="CVE-2024-35221" title="CVE-2024-35221" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35176" id="CVE-2024-35176" title="CVE-2024-35176" type="cve"/>
		</references>
		<description>CVE-2024-35221:Rubygems.org is the Ruby community'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.
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't parse untrusted XMLs.</description>
		<pkglist>
			<collection>
				<name>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2265</id>
		<title>An update for rubygem-actionpack is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28103" id="CVE-2024-28103" title="CVE-2024-28103" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23633" id="CVE-2022-23633" title="CVE-2022-23633" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2266</id>
		<title>An update for rubygem-actionview is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23913" id="CVE-2023-23913" title="CVE-2023-23913" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2267</id>
		<title>An update for rubygem-activesupport is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23633" id="CVE-2022-23633" title="CVE-2022-23633" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28120" id="CVE-2023-28120" title="CVE-2023-28120" type="cve"/>
		</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.
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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2268</id>
		<title>An update for rubygem-rack is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39316" id="CVE-2024-39316" title="CVE-2024-39316" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25126" id="CVE-2024-25126" title="CVE-2024-25126" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26141" id="CVE-2024-26141" title="CVE-2024-26141" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26146" id="CVE-2024-26146" title="CVE-2024-26146" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44570" id="CVE-2022-44570" title="CVE-2022-44570" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44571" id="CVE-2022-44571" title="CVE-2022-44571" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44572" id="CVE-2022-44572" title="CVE-2022-44572" type="cve"/>
		</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.
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.
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.
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.
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.
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.
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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2269</id>
		<title>An update for runc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3154" id="CVE-2024-3154" title="CVE-2024-3154" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2270</id>
		<title>An update for rust is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36113" id="CVE-2022-36113" title="CVE-2022-36113" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36114" id="CVE-2022-36114" title="CVE-2022-36114" type="cve"/>
		</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 &quot;ok&quot; 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 &quot;ok&quot; 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'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.
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.
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 &quot;zip bomb&quot;), 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'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>FusionOS</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2271</id>
		<title>An update for sbt is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46122" id="CVE-2023-46122" title="CVE-2023-46122" type="cve"/>
		</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'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>FusionOS</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2272</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37894" id="CVE-2024-37894" title="CVE-2024-37894" type="cve"/>
		</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>FusionOS</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2273</id>
		<title>An update for vte291 is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37535" id="CVE-2024-37535" title="CVE-2024-37535" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<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</release>
		<issued date="2024-08-08"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2320" id="CVE-2022-2320" title="CVE-2022-2320" type="cve"/>
		</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>FusionOS</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>
				</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>
				</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>
				</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>
				</package>
			</collection>
		</pkglist>
	</update>
</updates>
