<?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.u124.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.77.0.157.u124.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.77.0.157.u124.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.77.0.157.u124.fos23.aarch64.rpm</filename>
				</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-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-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"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24974" id="CVE-2024-24974" title="CVE-2024-24974" 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.
CVE-2024-24974:The interactive service in OpenVPN 2.6.9 and earlier allows the OpenVPN service pipe to be accessed remotely, which allows a remote attacker to interact with the privileged OpenVPN interactive service.</description>
		<pkglist>
			<collection>
				<name>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>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2275</id>
		<title>An update for bubblewrap is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42472" id="CVE-2024-42472" title="CVE-2024-42472" type="cve"/>
		</references>
		<description>CVE-2024-42472:Flatpak is a Linux application sandboxing and distribution framework. Prior to versions 1.14.0 and 1.15.10, a malicious or compromised Flatpak app using persistent directories could access and write files outside of what it would otherwise have access to, which is an attack on integrity and confidentiality.
When `persistent=subdir` is used in the application permissions (represented as `--persist=subdir` in the command-line interface), that means that an application which otherwise doesn't have access to the real user home directory will see an empty home directory with a writeable subdirectory `subdir`. Behind the scenes, this directory is actually a bind mount and the data is stored in the per-application directory as `~/.var/app/$APPID/subdir`. This allows existing apps that are not aware of the per-application directory to still work as intended without general home directory access.
However, the application does have write access to the application directory `~/.var/app/$APPID` where this directory is stored. If the source directory for the `persistent`/`--persist` option is replaced by a symlink, then the next time the application is started, the bind mount will follow the symlink and mount whatever it points to into the sandbox.
Partial protection against this vulnerability can be provided by patching Flatpak using the patches in commits ceec2ffc and 98f79773. However, this leaves a race condition that could be exploited by two instances of a malicious app running in parallel. Closing the race condition requires updating or patching the version of bubblewrap that is used by Flatpak to add the new `--bind-fd` option using the patch and then patching Flatpak to use it. If Flatpak has been configured at build-time with `-Dsystem_bubblewrap=bwrap` (1.15.x) or `--with-system-bubblewrap=bwrap` (1.14.x or older), or a similar option, then the version of bubblewrap that needs to be patched is a system copy that is distributed separately, typically `/usr/bin/bwrap`. This configuration is the one that is typically used in Linux distributions. If Flatpak has been configured at build-time with `-Dsystem_bubblewrap=` (1.15.x) or with `--without-system-bubblewrap` (1.14.x or older), then it is the bundled version of bubblewrap that is included with Flatpak that must be patched. This is typically installed as `/usr/libexec/flatpak-bwrap`. This configuration is the default when building from source code.
For the 1.14.x stable branch, these changes are included in Flatpak 1.14.10. The bundled version of bubblewrap included in this release has been updated to 0.6.3. For the 1.15.x development branch, these changes are included in Flatpak 1.15.10. The bundled version of bubblewrap in this release is a Meson &quot;wrap&quot; subproject, which has been updated to 0.10.0. The 1.12.x and 1.10.x branches will not be updated for this vulnerability. Long-term support OS distributions should backport the individual changes into their versions of Flatpak and bubblewrap, or update to newer versions if their stability policy allows it. As a workaround, avoid using applications using the `persistent` (`--persist`) permission.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="bubblewrap" release="1.u1.fos23" version="0.4.1">
					<filename>bubblewrap-0.4.1-1.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="bubblewrap-help" release="1.u1.fos23" version="0.4.1">
					<filename>bubblewrap-help-0.4.1-1.u1.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="bubblewrap" release="1.u1.fos23" version="0.4.1">
					<filename>bubblewrap-0.4.1-1.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2276</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7264" id="CVE-2024-7264" title="CVE-2024-7264" type="cve"/>
		</references>
		<description>CVE-2024-7264:libcurl's ASN1 parser code has the `GTime2str()` function, used for parsing an
ASN.1 Generalized Time field. If given an syntactically incorrect field, the
parser might end up using -1 for the length of the *time fraction*, leading to
a `strlen()` getting performed on a pointer to a heap buffer area that is not
(purposely) null terminated.
This flaw most likely leads to a crash, but can also lead to heap contents
getting returned to the application when
[CURLINFO_CERTINFO](https://curl.se/libcurl/c/CURLINFO_CERTINFO.html) is used.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="curl" release="30.u16.fos23" version="7.79.1">
					<filename>curl-7.79.1-30.u16.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="30.u16.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-30.u16.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="30.u16.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-30.u16.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="30.u16.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-30.u16.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="30.u16.fos23" version="7.79.1">
					<filename>curl-7.79.1-30.u16.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="30.u16.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-30.u16.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="30.u16.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-30.u16.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2277</id>
		<title>An update for docker is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41110" id="CVE-2024-41110" title="CVE-2024-41110" type="cve"/>
		</references>
		<description>CVE-2024-41110:Moby is an open-source project created by Docker for software containerization. A security vulnerability has been detected in certain versions of Docker Engine, which could allow an attacker to bypass authorization plugins (AuthZ) under specific circumstances. The base likelihood of this being exploited is low.
Using a specially-crafted API request, an Engine API client could make the daemon forward the request or response to an authorization plugin without the body. In certain circumstances, the authorization plugin may allow a request which it would have otherwise denied if the body had been forwarded to it.
A security issue was discovered In 2018, where an attacker could bypass AuthZ plugins using a specially crafted API request. This could lead to unauthorized actions, including privilege escalation. Although this issue was fixed in Docker Engine v18.09.1 in January 2019, the fix was not carried forward to later major versions, resulting in a regression. Anyone who depends on authorization plugins that introspect the request and/or response body to make access control decisions is potentially impacted.
Docker EE v19.03.x and all versions of Mirantis Container Runtime are not vulnerable.
docker-ce v27.1.1 containes patches to fix the vulnerability. Patches have also been merged into the master, 19.03, 20.0, 23.0, 24.0, 25.0, 26.0, and 26.1 release branches. If one is unable to upgrade immediately, avoid using AuthZ plugins and/or restrict access to the Docker API to trusted parties, following the principle of least privilege.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="docker" release="1.u3.fos23" version="20.10.24">
					<filename>docker-20.10.24-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="docker-engine" release="1.u3.fos23" version="20.10.24">
					<filename>docker-engine-20.10.24-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="docker-client" release="1.u3.fos23" version="20.10.24">
					<filename>docker-client-20.10.24-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="docker" release="1.u3.fos23" version="20.10.24">
					<filename>docker-20.10.24-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="docker-engine" release="1.u3.fos23" version="20.10.24">
					<filename>docker-engine-20.10.24-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="docker-client" release="1.u3.fos23" version="20.10.24">
					<filename>docker-client-20.10.24-1.u3.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2278</id>
		<title>An update for dovecot is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-3420" id="CVE-2015-3420" title="CVE-2015-3420" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-8652" id="CVE-2016-8652" title="CVE-2016-8652" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10957" id="CVE-2020-10957" title="CVE-2020-10957" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10958" id="CVE-2020-10958" title="CVE-2020-10958" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10967" id="CVE-2020-10967" title="CVE-2020-10967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12100" id="CVE-2020-12100" title="CVE-2020-12100" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12673" id="CVE-2020-12673" title="CVE-2020-12673" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12674" id="CVE-2020-12674" title="CVE-2020-12674" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-24386" id="CVE-2020-24386" title="CVE-2020-24386" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-25275" id="CVE-2020-25275" title="CVE-2020-25275" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-30550" id="CVE-2022-30550" title="CVE-2022-30550" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23184" id="CVE-2024-23184" title="CVE-2024-23184" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23185" id="CVE-2024-23185" title="CVE-2024-23185" type="cve"/>
		</references>
		<description>CVE-2015-3420:The ssl-proxy-openssl.c function in Dovecot before 2.2.17, when SSLv3 is disabled, allow remote attackers to cause a d
enial of service (login process crash) via vectors related to handshake failures.
CVE-2016-8652:The auth component in Dovecot before 2.2.27, when auth-policy is configured, allows a remote attackers to cause a denial of service (crash) by aborting authentication without setting a username.
CVE-2020-10957:A flaw was found in Dovecot, where it did not properly handle certain malformed NOOP commands. This flaw allows a malicious attacker to cause the submission, submission-login, or lmtp services to crash by sending specially crafted commands.
CVE-2020-10958:In Dovecot before 2.3.10.1, a crafted SMTP/LMTP message triggers an unauthenticated use-after-free bug in submission-login, submission, or lmtp, and can lead to a crash under circumstances involving many newlines after a command.
CVE-2020-10967:In Dovecot before 2.3.10.1, remote unauthenticated attackers can crash the lmtp or submission process by sending mail with an empty localpart.
CVE-2020-12100:In Dovecot before 2.3.11.3, uncontrolled recursion in submission, lmtp, and lda allows remote attackers to cause a denial of service (resource consumption) via a crafted e-mail message with deeply nested MIME parts.
CVE-2020-12673:In Dovecot before 2.3.11.3, sending a specially formatted NTLM request will crash the auth service because of an out-of-bounds read.
CVE-2020-12674:In Dovecot before 2.3.11.3, sending a specially formatted RPA request will crash the auth service because a length of zero is mishandled.
CVE-2020-24386:An issue was discovered in Dovecot before 2.3.13. By using IMAP IDLE, an authenticated attacker can trigger unhibernation via attacker-controlled parameters, leading to access to other users' email messages (and path disclosure).
CVE-2020-25275:Dovecot before 2.3.13 has Improper Input Validation in lda, lmtp, and imap, leading to an application crash via a crafted email message with certain choices for ten thousand MIME parts.
CVE-2022-30550:An issue was discovered in the auth component in Dovecot 2.2 and 2.3 before 2.3.20. When two passdb configuration entries exist with the same driver and args settings, incorrect username_filter and mechanism settings can be applied to passdb definitions. These incorrectly applied settings can lead to an unintended security configuration and can permit privilege escalation in certain configurations. The documentation does not advise against the use of passdb definitions that have the same driver and args settings. One such configuration would be where an administrator wishes to use the same PAM configuration or passwd file for both normal and master users but use the username_filter setting to restrict which of the users is able to be a master user.
CVE-2024-23184:Having a large number of address headers (From, To, Cc, Bcc, etc.) becomes excessively CPU intensive. With 100k header lines CPU usage is already 12 seconds, and in a production environment we observed 500k header lines taking 18 minutes to parse. Since this can be triggered by external actors sending emails to a victim, this is a security issue.
CVE-2024-23185:Very large headers can cause resource exhaustion when parsing message. The message-parser normally reads reasonably sized chunks of the message. However, when it feeds them to message-header-parser, it starts building up full_value buffer out of the smaller chunks. The full_value buffer has no size limit, so large headers can cause large memory usage. It doesn t matter whether it s a single long header line, or a single header split into multiple lines. This bug exists in all Dovecot versions.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="dovecot" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-2.3.15-6.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="dovecot-devel" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-devel-2.3.15-6.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="dovecot-help" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-help-2.3.15-6.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-2.3.15-6.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot-devel" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-devel-2.3.15-6.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="dovecot-help" release="6.u1.fos23" version="2.3.15">
					<filename>dovecot-help-2.3.15-6.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2279</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<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-5535:Issue summary: Calling the OpenSSL API function SSL_select_next_proto with anempty supported client protocols buffer may cause a crash or memory contents tobe sent to the peer.Impact summary: A buffer overread can have a range of potential consequencessuch as unexpected application beahviour or a crash. In particular this issuecould result in up to 255 bytes of arbitrary private data from memory being sentto the peer leading to a loss of confidentiality. However, only applicationsthat directly call the SSL_select_next_proto function with a 0 length list ofsupported client protocols are affected by this issue. This would normally neverbe a valid scenario and is typically not under attacker control but may occur byaccident in the case of a configuration or programming error in the callingapplication.The OpenSSL API function SSL_select_next_proto is typically used by TLSapplications that support ALPN (Application Layer Protocol Negotiation) or NPN(Next Protocol Negotiation). NPN is older, was never standardised andis deprecated in favour of ALPN. We believe that ALPN is significantly morewidely deployed than NPN. The SSL_select_next_proto function accepts a list ofprotocols from the server and a list of protocols from the client and returnsthe first protocol that appears in the server list that also appears in theclient list. In the case of no overlap between the two lists it returns thefirst item in the client list. In either case it will signal whether an overlapbetween the two lists was found. In the case where SSL_select_next_proto iscalled with a zero length client list it fails to notice this condition andreturns the memory immediately following the client list pointer (and reportsthat there was no overlap in the lists).This function is typically called from a server side application callback forALPN or a client side application callback for NPN. In the case of ALPN the listof protocols supplied by the client is guaranteed by libssl to never be zero inlength. The list of server protocols comes from the application and should nevernormally be expected to be of zero length. In this case if theSSL_select_next_proto function has been called as expected (with the listsupplied by the client passed in the client/client_len parameters), then theapplication will not be vulnerable to this issue. If the application hasaccidentally been configured with a zero length server list, and hasaccidentally passed that zero length server list in the client/client_lenparameters, and has additionally failed to correctly handle a  no overlap response (which would normally result in a handshake failure in ALPN) then itwill be vulnerable to this problem.In the case of NPN, the protocol permits the client to opportunistically selecta protocol when there is no overlap. OpenSSL returns the first client protocolin the no overlap case in support of this. The list of client protocols comesfrom the application and should never normally be expected to be of zero length.However if the SSL_select_next_proto function is accidentally called with aclient_len of 0 then an invalid memory pointer will be returned instead. If theapplication uses this output as the opportunistic protocol then the loss ofconfidentiality will occur.This issue has been assessed as Low severity because applications are mostlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is notwidely used. It also requires an application configuration or programming error.Finally, this issue would not typically be under attacker control making activeexploitation unlikely.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.Due to the low severity of this issue we are not issuing new releases ofOpenSSL at this time. The fix will be included in the next releases when theybecome available.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="19.u8.fos23" version="202011">
					<filename>edk2-devel-202011-19.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="19.u8.fos23" version="202011">
					<filename>python3-edk2-devel-202011-19.u8.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="19.u8.fos23" version="202011">
					<filename>edk2-help-202011-19.u8.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="19.u8.fos23" version="202011">
					<filename>edk2-ovmf-202011-19.u8.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="19.u8.fos23" version="202011">
					<filename>edk2-devel-202011-19.u8.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2280</id>
		<title>An update for flatpak is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42472" id="CVE-2024-42472" title="CVE-2024-42472" type="cve"/>
		</references>
		<description>CVE-2024-42472:Flatpak is a Linux application sandboxing and distribution framework. Prior to versions 1.14.0 and 1.15.10, a malicious or compromised Flatpak app using persistent directories could access and write files outside of what it would otherwise have access to, which is an attack on integrity and confidentiality.
When `persistent=subdir` is used in the application permissions (represented as `--persist=subdir` in the command-line interface), that means that an application which otherwise doesn't have access to the real user home directory will see an empty home directory with a writeable subdirectory `subdir`. Behind the scenes, this directory is actually a bind mount and the data is stored in the per-application directory as `~/.var/app/$APPID/subdir`. This allows existing apps that are not aware of the per-application directory to still work as intended without general home directory access.
However, the application does have write access to the application directory `~/.var/app/$APPID` where this directory is stored. If the source directory for the `persistent`/`--persist` option is replaced by a symlink, then the next time the application is started, the bind mount will follow the symlink and mount whatever it points to into the sandbox.
Partial protection against this vulnerability can be provided by patching Flatpak using the patches in commits ceec2ffc and 98f79773. However, this leaves a race condition that could be exploited by two instances of a malicious app running in parallel. Closing the race condition requires updating or patching the version of bubblewrap that is used by Flatpak to add the new `--bind-fd` option using the patch and then patching Flatpak to use it. If Flatpak has been configured at build-time with `-Dsystem_bubblewrap=bwrap` (1.15.x) or `--with-system-bubblewrap=bwrap` (1.14.x or older), or a similar option, then the version of bubblewrap that needs to be patched is a system copy that is distributed separately, typically `/usr/bin/bwrap`. This configuration is the one that is typically used in Linux distributions. If Flatpak has been configured at build-time with `-Dsystem_bubblewrap=` (1.15.x) or with `--without-system-bubblewrap` (1.14.x or older), then it is the bundled version of bubblewrap that is included with Flatpak that must be patched. This is typically installed as `/usr/libexec/flatpak-bwrap`. This configuration is the default when building from source code.
For the 1.14.x stable branch, these changes are included in Flatpak 1.14.10. The bundled version of bubblewrap included in this release has been updated to 0.6.3. For the 1.15.x development branch, these changes are included in Flatpak 1.15.10. The bundled version of bubblewrap in this release is a Meson &quot;wrap&quot; subproject, which has been updated to 0.10.0. The 1.12.x and 1.10.x branches will not be updated for this vulnerability. Long-term support OS distributions should backport the individual changes into their versions of Flatpak and bubblewrap, or update to newer versions if their stability policy allows it. As a workaround, avoid using applications using the `persistent` (`--persist`) permission.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="flatpak" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-1.10.2-9.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="flatpak-devel" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-devel-1.10.2-9.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="flatpak-help" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-help-1.10.2-9.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="flatpak" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-1.10.2-9.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="flatpak-devel" release="9.u4.fos23" version="1.10.2">
					<filename>flatpak-devel-1.10.2-9.u4.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2281</id>
		<title>An update for giflib is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-23922" id="CVE-2020-23922" title="CVE-2020-23922" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48161" id="CVE-2023-48161" title="CVE-2023-48161" type="cve"/>
		</references>
		<description>CVE-2020-23922:An issue was discovered in giflib through 5.1.4. DumpScreen2RGB in gif2rgb.c has a heap-based buffer over-read.
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="1.u5.fos23" version="5.2.2">
					<filename>giflib-5.2.2-1.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-devel" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-devel-5.2.2-1.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="giflib-utils" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-utils-5.2.2-1.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="giflib-help" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-help-5.2.2-1.u5.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="giflib" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-5.2.2-1.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-devel" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-devel-5.2.2-1.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="giflib-utils" release="1.u5.fos23" version="5.2.2">
					<filename>giflib-utils-5.2.2-1.u5.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2282</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"/>
		</references>
		<description>CVE-2024-21131:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
CVE-2024-21138:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21140:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
CVE-2024-21144:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21145:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
CVE-2024-21147:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.422.b05-0.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.422.b05-0.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u3.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u3.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2283</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"/>
		</references>
		<description>CVE-2024-21131:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
CVE-2024-21138:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21140:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
CVE-2024-21144:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21145:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
CVE-2024-21147:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2284</id>
		<title>An update for java-17-openjdk is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"/>
		</references>
		<description>CVE-2024-21131:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
CVE-2024-21138:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21140:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
CVE-2024-21144:Vulnerability in the Oracle Java SE, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Concurrency).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21145:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: 2D).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).
CVE-2024-21147:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u411, 8u411-perf, 11.0.23, 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM for JDK: 17.0.11, 21.0.3, 22.0.1; Oracle GraalVM Enterprise Edition: 20.3.14 and  21.3.10. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized creation, deletion or modification access to critical data or all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized access to critical data or complete access to all Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 7.4 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="java-17-openjdk" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u5.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.u5.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2285</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<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-2024-40916" id="CVE-2024-40916" title="CVE-2024-40916" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35963" id="CVE-2024-35963" title="CVE-2024-35963" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48878" id="CVE-2022-48878" title="CVE-2022-48878" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38570" id="CVE-2024-38570" title="CVE-2024-38570" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42160" id="CVE-2024-42160" title="CVE-2024-42160" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41087" id="CVE-2024-41087" title="CVE-2024-41087" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40902" id="CVE-2024-40902" title="CVE-2024-40902" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41073" id="CVE-2024-41073" title="CVE-2024-41073" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42271" id="CVE-2024-42271" title="CVE-2024-42271" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42284" id="CVE-2024-42284" title="CVE-2024-42284" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42285" id="CVE-2024-42285" title="CVE-2024-42285" 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-38607" id="CVE-2024-38607" title="CVE-2024-38607" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37353" id="CVE-2024-37353" title="CVE-2024-37353" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52743" id="CVE-2023-52743" title="CVE-2023-52743" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38582" id="CVE-2024-38582" title="CVE-2024-38582" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39467" id="CVE-2024-39467" title="CVE-2024-39467" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38586" id="CVE-2024-38586" title="CVE-2024-38586" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36489" id="CVE-2024-36489" title="CVE-2024-36489" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38579" id="CVE-2024-38579" title="CVE-2024-38579" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38554" id="CVE-2024-38554" title="CVE-2024-38554" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38546" id="CVE-2024-38546" title="CVE-2024-38546" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38637" id="CVE-2024-38637" title="CVE-2024-38637" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38780" id="CVE-2024-38780" title="CVE-2024-38780" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38602" id="CVE-2024-38602" title="CVE-2024-38602" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48765" id="CVE-2022-48765" title="CVE-2022-48765" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38603" id="CVE-2024-38603" title="CVE-2024-38603" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39301" id="CVE-2024-39301" title="CVE-2024-39301" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38621" id="CVE-2024-38621" title="CVE-2024-38621" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38547" id="CVE-2024-38547" title="CVE-2024-38547" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39277" id="CVE-2024-39277" title="CVE-2024-39277" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39469" id="CVE-2024-39469" title="CVE-2024-39469" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26816" id="CVE-2024-26816" title="CVE-2024-26816" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34027" id="CVE-2024-34027" title="CVE-2024-34027" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48733" id="CVE-2022-48733" title="CVE-2022-48733" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38558" id="CVE-2024-38558" title="CVE-2024-38558" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4458" id="CVE-2023-4458" title="CVE-2023-4458" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38548" id="CVE-2024-38548" title="CVE-2024-38548" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36478" id="CVE-2024-36478" title="CVE-2024-36478" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39480" id="CVE-2024-39480" title="CVE-2024-39480" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38540" id="CVE-2024-38540" title="CVE-2024-38540" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38615" id="CVE-2024-38615" title="CVE-2024-38615" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52757" id="CVE-2023-52757" title="CVE-2023-52757" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52755" id="CVE-2023-52755" title="CVE-2023-52755" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39484" id="CVE-2024-39484" title="CVE-2024-39484" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39472" id="CVE-2024-39472" title="CVE-2024-39472" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38598" id="CVE-2024-38598" title="CVE-2024-38598" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35899" id="CVE-2024-35899" title="CVE-2024-35899" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38583" id="CVE-2024-38583" title="CVE-2024-38583" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35988" id="CVE-2024-35988" title="CVE-2024-35988" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39489" id="CVE-2024-39489" title="CVE-2024-39489" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39487" id="CVE-2024-39487" title="CVE-2024-39487" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40905" id="CVE-2024-40905" title="CVE-2024-40905" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40931" id="CVE-2024-40931" title="CVE-2024-40931" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39500" id="CVE-2024-39500" title="CVE-2024-39500" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39488" id="CVE-2024-39488" title="CVE-2024-39488" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40974" id="CVE-2024-40974" title="CVE-2024-40974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47200" id="CVE-2021-47200" title="CVE-2021-47200" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40943" id="CVE-2024-40943" title="CVE-2024-40943" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52674" id="CVE-2023-52674" title="CVE-2023-52674" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35904" id="CVE-2024-35904" title="CVE-2024-35904" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40984" id="CVE-2024-40984" title="CVE-2024-40984" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40971" id="CVE-2024-40971" title="CVE-2024-40971" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39505" id="CVE-2024-39505" title="CVE-2024-39505" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40953" id="CVE-2024-40953" title="CVE-2024-40953" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52781" id="CVE-2023-52781" title="CVE-2023-52781" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40972" id="CVE-2024-40972" title="CVE-2024-40972" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41005" id="CVE-2024-41005" title="CVE-2024-41005" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39508" id="CVE-2024-39508" title="CVE-2024-39508" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52833" id="CVE-2023-52833" title="CVE-2023-52833" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40932" id="CVE-2024-40932" title="CVE-2024-40932" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39506" id="CVE-2024-39506" title="CVE-2024-39506" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40960" id="CVE-2024-40960" title="CVE-2024-40960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36939" id="CVE-2024-36939" title="CVE-2024-36939" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48666" id="CVE-2022-48666" title="CVE-2022-48666" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47432" id="CVE-2021-47432" title="CVE-2021-47432" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40983" id="CVE-2024-40983" title="CVE-2024-40983" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39499" id="CVE-2024-39499" title="CVE-2024-39499" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40945" id="CVE-2024-40945" title="CVE-2024-40945" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37078" id="CVE-2024-37078" title="CVE-2024-37078" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40967" id="CVE-2024-40967" title="CVE-2024-40967" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40987" id="CVE-2024-40987" title="CVE-2024-40987" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40995" id="CVE-2024-40995" title="CVE-2024-40995" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38559" id="CVE-2024-38559" title="CVE-2024-38559" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38578" id="CVE-2024-38578" title="CVE-2024-38578" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41004" id="CVE-2024-41004" title="CVE-2024-41004" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40929" id="CVE-2024-40929" title="CVE-2024-40929" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40941" id="CVE-2024-40941" title="CVE-2024-40941" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38618" id="CVE-2024-38618" title="CVE-2024-38618" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40968" id="CVE-2024-40968" title="CVE-2024-40968" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40912" id="CVE-2024-40912" title="CVE-2024-40912" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40990" id="CVE-2024-40990" title="CVE-2024-40990" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40980" id="CVE-2024-40980" title="CVE-2024-40980" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34777" id="CVE-2024-34777" title="CVE-2024-34777" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48814" id="CVE-2022-48814" title="CVE-2022-48814" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38568" id="CVE-2024-38568" title="CVE-2024-38568" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35837" id="CVE-2024-35837" title="CVE-2024-35837" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41009" id="CVE-2024-41009" title="CVE-2024-41009" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35931" id="CVE-2024-35931" title="CVE-2024-35931" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39494" id="CVE-2024-39494" title="CVE-2024-39494" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41007" id="CVE-2024-41007" title="CVE-2024-41007" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40947" id="CVE-2024-40947" title="CVE-2024-40947" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48844" id="CVE-2022-48844" title="CVE-2022-48844" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40982" id="CVE-2024-40982" title="CVE-2024-40982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39475" id="CVE-2024-39475" title="CVE-2024-39475" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40956" id="CVE-2024-40956" title="CVE-2024-40956" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40981" id="CVE-2024-40981" title="CVE-2024-40981" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40904" id="CVE-2024-40904" title="CVE-2024-40904" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39509" id="CVE-2024-39509" title="CVE-2024-39509" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52679" id="CVE-2023-52679" title="CVE-2023-52679" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38619" id="CVE-2024-38619" title="CVE-2024-38619" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48859" id="CVE-2022-48859" title="CVE-2022-48859" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40915" id="CVE-2024-40915" title="CVE-2024-40915" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47205" id="CVE-2021-47205" title="CVE-2021-47205" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38611" id="CVE-2024-38611" title="CVE-2024-38611" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41011" id="CVE-2024-41011" title="CVE-2024-41011" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40988" id="CVE-2024-40988" title="CVE-2024-40988" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42090" id="CVE-2024-42090" title="CVE-2024-42090" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41069" id="CVE-2024-41069" title="CVE-2024-41069" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38627" id="CVE-2024-38627" title="CVE-2024-38627" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38561" id="CVE-2024-38561" title="CVE-2024-38561" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47382" id="CVE-2021-47382" title="CVE-2021-47382" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41040" id="CVE-2024-41040" title="CVE-2024-41040" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40999" id="CVE-2024-40999" title="CVE-2024-40999" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41019" id="CVE-2024-41019" title="CVE-2024-41019" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40959" id="CVE-2024-40959" title="CVE-2024-40959" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41041" id="CVE-2024-41041" title="CVE-2024-41041" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41077" id="CVE-2024-41077" title="CVE-2024-41077" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41080" id="CVE-2024-41080" title="CVE-2024-41080" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39471" id="CVE-2024-39471" title="CVE-2024-39471" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42115" id="CVE-2024-42115" title="CVE-2024-42115" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42097" id="CVE-2024-42097" title="CVE-2024-42097" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42086" id="CVE-2024-42086" title="CVE-2024-42086" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42228" id="CVE-2024-42228" title="CVE-2024-42228" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41014" id="CVE-2024-41014" title="CVE-2024-41014" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41063" id="CVE-2024-41063" title="CVE-2024-41063" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42084" id="CVE-2024-42084" title="CVE-2024-42084" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40961" id="CVE-2024-40961" title="CVE-2024-40961" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41090" id="CVE-2024-41090" title="CVE-2024-41090" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41091" id="CVE-2024-41091" title="CVE-2024-41091" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41020" id="CVE-2024-41020" title="CVE-2024-41020" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42068" id="CVE-2024-42068" title="CVE-2024-42068" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41048" id="CVE-2024-41048" title="CVE-2024-41048" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52887" id="CVE-2023-52887" title="CVE-2023-52887" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42092" id="CVE-2024-42092" title="CVE-2024-42092" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41081" id="CVE-2024-41081" title="CVE-2024-41081" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42161" id="CVE-2024-42161" title="CVE-2024-42161" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40910" id="CVE-2024-40910" title="CVE-2024-40910" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41046" id="CVE-2024-41046" title="CVE-2024-41046" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41044" id="CVE-2024-41044" title="CVE-2024-41044" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42145" id="CVE-2024-42145" title="CVE-2024-42145" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41072" id="CVE-2024-41072" title="CVE-2024-41072" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41035" id="CVE-2024-41035" title="CVE-2024-41035" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42155" id="CVE-2024-42155" title="CVE-2024-42155" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42129" id="CVE-2024-42129" title="CVE-2024-42129" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41023" id="CVE-2024-41023" title="CVE-2024-41023" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42080" id="CVE-2024-42080" title="CVE-2024-42080" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41097" id="CVE-2024-41097" title="CVE-2024-41097" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42106" id="CVE-2024-42106" title="CVE-2024-42106" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42224" id="CVE-2024-42224" title="CVE-2024-42224" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41013" id="CVE-2024-41013" title="CVE-2024-41013" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41070" id="CVE-2024-41070" title="CVE-2024-41070" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41062" id="CVE-2024-41062" title="CVE-2024-41062" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42089" id="CVE-2024-42089" title="CVE-2024-42089" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42076" id="CVE-2024-42076" title="CVE-2024-42076" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41089" id="CVE-2024-41089" title="CVE-2024-41089" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42098" id="CVE-2024-42098" title="CVE-2024-42098" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42077" id="CVE-2024-42077" title="CVE-2024-42077" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39497" id="CVE-2024-39497" title="CVE-2024-39497" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42096" id="CVE-2024-42096" title="CVE-2024-42096" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41079" id="CVE-2024-41079" title="CVE-2024-41079" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42101" id="CVE-2024-42101" title="CVE-2024-42101" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42162" id="CVE-2024-42162" title="CVE-2024-42162" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42124" id="CVE-2024-42124" title="CVE-2024-42124" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42094" id="CVE-2024-42094" title="CVE-2024-42094" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41012" id="CVE-2024-41012" title="CVE-2024-41012" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42093" id="CVE-2024-42093" title="CVE-2024-42093" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52888" id="CVE-2023-52888" title="CVE-2023-52888" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41078" id="CVE-2024-41078" title="CVE-2024-41078" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41027" id="CVE-2024-41027" title="CVE-2024-41027" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47582" id="CVE-2021-47582" title="CVE-2021-47582" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41034" id="CVE-2024-41034" title="CVE-2024-41034" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42157" id="CVE-2024-42157" title="CVE-2024-42157" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48827" id="CVE-2022-48827" title="CVE-2022-48827" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42128" id="CVE-2024-42128" title="CVE-2024-42128" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40942" id="CVE-2024-40942" title="CVE-2024-40942" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42154" id="CVE-2024-42154" title="CVE-2024-42154" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41065" id="CVE-2024-41065" title="CVE-2024-41065" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42095" id="CVE-2024-42095" title="CVE-2024-42095" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42114" id="CVE-2024-42114" title="CVE-2024-42114" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42102" id="CVE-2024-42102" title="CVE-2024-42102" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42225" id="CVE-2024-42225" title="CVE-2024-42225" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41042" id="CVE-2024-41042" title="CVE-2024-41042" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42247" id="CVE-2024-42247" title="CVE-2024-42247" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42223" id="CVE-2024-42223" title="CVE-2024-42223" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42246" id="CVE-2024-42246" title="CVE-2024-42246" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42244" id="CVE-2024-42244" title="CVE-2024-42244" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41092" id="CVE-2024-41092" title="CVE-2024-41092" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42087" id="CVE-2024-42087" title="CVE-2024-42087" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42143" id="CVE-2024-42143" title="CVE-2024-42143" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42229" id="CVE-2024-42229" title="CVE-2024-42229" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42156" id="CVE-2024-42156" title="CVE-2024-42156" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35840" id="CVE-2024-35840" title="CVE-2024-35840" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36971" id="CVE-2024-36971" title="CVE-2024-36971" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37356" id="CVE-2024-37356" title="CVE-2024-37356" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35879" id="CVE-2024-35879" title="CVE-2024-35879" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39362" id="CVE-2024-39362" title="CVE-2024-39362" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27415" id="CVE-2024-27415" title="CVE-2024-27415" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35839" id="CVE-2024-35839" title="CVE-2024-35839" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35819" id="CVE-2024-35819" title="CVE-2024-35819" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47366" id="CVE-2021-47366" title="CVE-2021-47366" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36968" id="CVE-2024-36968" title="CVE-2024-36968" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47469" id="CVE-2021-47469" title="CVE-2021-47469" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38588" id="CVE-2024-38588" title="CVE-2024-38588" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47599" id="CVE-2021-47599" title="CVE-2021-47599" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38623" id="CVE-2024-38623" title="CVE-2024-38623" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26921" id="CVE-2024-26921" title="CVE-2024-26921" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26592" id="CVE-2024-26592" title="CVE-2024-26592" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38556" id="CVE-2024-38556" title="CVE-2024-38556" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48744" id="CVE-2022-48744" title="CVE-2022-48744" type="cve"/>
		</references>
		<description>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-2024-40916:In the Linux kernel, the following vulnerability has been resolved:
drm/exynos: hdmi: report safe 640x480 mode as a fallback when no EDID found
When reading EDID fails and driver reports no modes available, the DRM
core adds an artificial 1024x786 mode to the connector. Unfortunately
some variants of the Exynos HDMI (like the one in Exynos4 SoCs) are not
able to drive such mode, so report a safe 640x480 mode instead of nothing
in case of the EDID reading failure.
This fixes the following issue observed on Trats2 board since commit
13d5b040363c (&quot;drm/exynos: do not return negative values from .get_modes()&quot;):
[drm] Exynos DRM: using 11c00000.fimd device for DMA mapping operations
exynos-drm exynos-drm: bound 11c00000.fimd (ops fimd_component_ops)
exynos-drm exynos-drm: bound 12c10000.mixer (ops mixer_component_ops)
exynos-dsi 11c80000.dsi: [drm:samsung_dsim_host_attach] Attached s6e8aa0 device (lanes:4 bpp:24 mode-flags:0x10b)
exynos-drm exynos-drm: bound 11c80000.dsi (ops exynos_dsi_component_ops)
exynos-drm exynos-drm: bound 12d00000.hdmi (ops hdmi_component_ops)
[drm] Initialized exynos 1.1.0 20180330 for exynos-drm on minor 1
exynos-hdmi 12d00000.hdmi: [drm:hdmiphy_enable.part.0] *ERROR* PLL could not reach steady state
panel-samsung-s6e8aa0 11c80000.dsi.0: ID: 0xa2, 0x20, 0x8c
exynos-mixer 12c10000.mixer: timeout waiting for VSYNC
------------[ cut here ]------------
WARNING: CPU: 1 PID: 11 at drivers/gpu/drm/drm_atomic_helper.c:1682 drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
[CRTC:70:crtc-1] vblank wait timed out
Modules linked in:
CPU: 1 PID: 11 Comm: kworker/u16:0 Not tainted 6.9.0-rc5-next-20240424 #14913
Hardware name: Samsung Exynos (Flattened Device Tree)
Workqueue: events_unbound deferred_probe_work_func
Call trace:
 unwind_backtrace from show_stack+0x10/0x14
 show_stack from dump_stack_lvl+0x68/0x88
 dump_stack_lvl from __warn+0x7c/0x1c4
 __warn from warn_slowpath_fmt+0x11c/0x1a8
 warn_slowpath_fmt from drm_atomic_helper_wait_for_vblanks.part.0+0x2b0/0x2b8
 drm_atomic_helper_wait_for_vblanks.part.0 from drm_atomic_helper_commit_tail_rpm+0x7c/0x8c
 drm_atomic_helper_commit_tail_rpm from commit_tail+0x9c/0x184
 commit_tail from drm_atomic_helper_commit+0x168/0x190
 drm_atomic_helper_commit from drm_atomic_commit+0xb4/0xe0
 drm_atomic_commit from drm_client_modeset_commit_atomic+0x23c/0x27c
 drm_client_modeset_commit_atomic from drm_client_modeset_commit_locked+0x60/0x1cc
 drm_client_modeset_commit_locked from drm_client_modeset_commit+0x24/0x40
 drm_client_modeset_commit from __drm_fb_helper_restore_fbdev_mode_unlocked+0x9c/0xc4
 __drm_fb_helper_restore_fbdev_mode_unlocked from drm_fb_helper_set_par+0x2c/0x3c
 drm_fb_helper_set_par from fbcon_init+0x3d8/0x550
 fbcon_init from visual_init+0xc0/0x108
 visual_init from do_bind_con_driver+0x1b8/0x3a4
 do_bind_con_driver from do_take_over_console+0x140/0x1ec
 do_take_over_console from do_fbcon_takeover+0x70/0xd0
 do_fbcon_takeover from fbcon_fb_registered+0x19c/0x1ac
 fbcon_fb_registered from register_framebuffer+0x190/0x21c
 register_framebuffer from __drm_fb_helper_initial_config_and_unlock+0x350/0x574
 __drm_fb_helper_initial_config_and_unlock from exynos_drm_fbdev_client_hotplug+0x6c/0xb0
 exynos_drm_fbdev_client_hotplug from drm_client_register+0x58/0x94
 drm_client_register from exynos_drm_bind+0x160/0x190
 exynos_drm_bind from try_to_bring_up_aggregate_device+0x200/0x2d8
 try_to_bring_up_aggregate_device from __component_add+0xb0/0x170
 __component_add from mixer_probe+0x74/0xcc
 mixer_probe from platform_probe+0x5c/0xb8
 platform_probe from really_probe+0xe0/0x3d8
 really_probe from __driver_probe_device+0x9c/0x1e4
 __driver_probe_device from driver_probe_device+0x30/0xc0
 driver_probe_device from __device_attach_driver+0xa8/0x120
 __device_attach_driver from bus_for_each_drv+0x80/0xcc
 bus_for_each_drv from __device_attach+0xac/0x1fc
 __device_attach from bus_probe_device+0x8c/0x90
 bus_probe_device from deferred_probe_work_func+0
---truncated---
CVE-2024-35963:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_sock: Fix not validating setsockopt user input
Check user input length before copying data.
CVE-2022-48878:In the Linux kernel, the following vulnerability has been resolved: Bluetooth: hci_qca: Fix driver shutdown on closed serdev The driver shutdown callback (which sends EDL_SOC_RESET to the device over serdev) should not be invoked when HCI device is not open (e.g. if hci_dev_open_sync() failed), because the serdev and its TTY are not open either. Also skip this step if device is powered off (qca_power_shutdown()). The shutdown callback causes use-after-free during system reboot with Qualcomm Atheros Bluetooth: Unable to handle kernel paging request at virtual address 0072662f67726fd7 ... CPU: 6 PID: 1 Comm: systemd-shutdow Tainted: G W 6.1.0-rt5-00325-g8a5f56bcfcca #8 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: tty_driver_flush_buffer+0x4/0x30 serdev_device_write_flush+0x24/0x34 qca_serdev_shutdown+0x80/0x130 [hci_uart] device_shutdown+0x15c/0x260 kernel_restart+0x48/0xac KASAN report: BUG: KASAN: use-after-free in tty_driver_flush_buffer+0x1c/0x50 Read of size 8 at addr ffff16270c2e0018 by task systemd-shutdow/1 CPU: 7 PID: 1 Comm: systemd-shutdow Not tainted 6.1.0-next-20221220-00014-gb85aaf97fb01-dirty #28 Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT) Call trace: dump_backtrace.part.0+0xdc/0xf0 show_stack+0x18/0x30 dump_stack_lvl+0x68/0x84 print_report+0x188/0x488 kasan_report+0xa4/0xf0 __asan_load8+0x80/0xac tty_driver_flush_buffer+0x1c/0x50 ttyport_write_flush+0x34/0x44 serdev_device_write_flush+0x48/0x60 qca_serdev_shutdown+0x124/0x274 device_shutdown+0x1e8/0x350 kernel_restart+0x48/0xb0 __do_sys_reboot+0x244/0x2d0 __arm64_sys_reboot+0x54/0x70 invoke_syscall+0x60/0x190 el0_svc_common.constprop.0+0x7c/0x160 do_el0_svc+0x44/0xf0 el0_svc+0x2c/0x6c el0t_64_sync_handler+0xbc/0x140 el0t_64_sync+0x190/0x194
CVE-2024-38570:In the Linux kernel, the following vulnerability has been resolved:
gfs2: Fix potential glock use-after-free on unmount
When a DLM lockspace is released and there ares still locks in that
lockspace, DLM will unlock those locks automatically.  Commit
fb6791d100d1b started exploiting this behavior to speed up filesystem
unmount: gfs2 would simply free glocks it didn't want to unlock and then
release the lockspace.  This didn't take the bast callbacks for
asynchronous lock contention notifications into account, which remain
active until until a lock is unlocked or its lockspace is released.
To prevent those callbacks from accessing deallocated objects, put the
glocks that should not be unlocked on the sd_dead_glocks list, release
the lockspace, and only then free those glocks.
As an additional measure, ignore unexpected ast and bast callbacks if
the receiving glock is dead.
CVE-2024-42160:In the Linux kernel, the following vulnerability has been resolved:
f2fs: check validation of fault attrs in f2fs_build_fault_attr()
- It missed to check validation of fault attrs in parse_options(),
let's fix to add check condition in f2fs_build_fault_attr().
- Use f2fs_build_fault_attr() in __sbi_store() to clean up code.
CVE-2024-41087:In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix double free on error
If e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jump
to the err_out label, which will call devres_release_group().
devres_release_group() will trigger a call to ata_host_release().
ata_host_release() calls kfree(host), so executing the kfree(host) in
ata_host_alloc() will lead to a double free:
kernel BUG at mm/slub.c:553!
Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
CPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:kfree+0x2cf/0x2f0
Code: 5d 41 5e 41 5f 5d e9 80 d6 ff ff 4d 89 f1 41 b8 01 00 00 00 48 89 d9 48 89 da
RSP: 0018:ffffc90000f377f0 EFLAGS: 00010246
RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320
RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0
RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000
R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780
R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006
FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? die+0x2e/0x50
 ? do_trap+0xca/0x110
 ? do_error_trap+0x6a/0x90
 ? kfree+0x2cf/0x2f0
 ? exc_invalid_op+0x50/0x70
 ? kfree+0x2cf/0x2f0
 ? asm_exc_invalid_op+0x1a/0x20
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? ata_host_alloc+0xf5/0x120 [libata]
 ? kfree+0x2cf/0x2f0
 ata_host_alloc+0xf5/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]
Ensure that we will not call kfree(host) twice, by performing the kfree()
only if the devres_open_group() call failed.
CVE-2024-40902:In the Linux kernel, the following vulnerability has been resolved:
jfs: xattr: fix buffer overflow for invalid xattr
When an xattr size is not what is expected, it is printed out to the
kernel log in hex format as a form of debugging.  But when that xattr
size is bigger than the expected size, printing it out can cause an
access off the end of the buffer.
Fix this all up by properly restricting the size of the debug hex dump
in the kernel log.
CVE-2024-41073:In the Linux kernel, the following vulnerability has been resolved:
nvme: avoid double free special payload
If a discard request needs to be retried, and that retry may fail before
a new special payload is added, a double free will result. Clear the
RQF_SPECIAL_LOAD when the request is cleaned.
CVE-2024-42271:In the Linux kernel, the following vulnerability has been resolved:net/iucv: fix use after free in iucv_sock_close()iucv_sever_path() is called from process context and from bh context.iucv-&gt;path is used as indicator whether somebody else is taking care ofsevering the path (or it is already removed / never existed).This needs to be done with atomic compare and swap, otherwise there is asmall window where iucv_sock_close() will try to work with a path that hasalready been severed and freed by iucv_callback_connrej() called byiucv_tasklet_fn().Example:[452744.123844] Call Trace:[452744.123845] ([&lt;0000001e87f03880&gt;] 0x1e87f03880)[452744.123966]  [&lt;00000000d593001e&gt;] iucv_path_sever+0x96/0x138[452744.124330]  [&lt;000003ff801ddbca&gt;] iucv_sever_path+0xc2/0xd0 [af_iucv][452744.124336]  [&lt;000003ff801e01b6&gt;] iucv_sock_close+0xa6/0x310 [af_iucv][452744.124341]  [&lt;000003ff801e08cc&gt;] iucv_sock_release+0x3c/0xd0 [af_iucv][452744.124345]  [&lt;00000000d574794e&gt;] __sock_release+0x5e/0xe8[452744.124815]  [&lt;00000000d5747a0c&gt;] sock_close+0x34/0x48[452744.124820]  [&lt;00000000d5421642&gt;] __fput+0xba/0x268[452744.124826]  [&lt;00000000d51b382c&gt;] task_work_run+0xbc/0xf0[452744.124832]  [&lt;00000000d5145710&gt;] do_notify_resume+0x88/0x90[452744.124841]  [&lt;00000000d5978096&gt;] system_call+0xe2/0x2c8[452744.125319] Last Breaking-Event-Address:[452744.125321]  [&lt;00000000d5930018&gt;] iucv_path_sever+0x90/0x138[452744.125324][452744.125325] Kernel panic - not syncing: Fatal exception in interruptNote that bh_lock_sock() is not serializing the tasklet context againstprocess context, because the check for sock_owned_by_user() andcorresponding handling is missing.Ideas for a future clean-up patch:A) Correct usage of bh_lock_sock() in tasklet context, as described inRe-enqueue, if needed. This may require adding return values to thetasklet functions and thus changes to all users of iucv.B) Change iucv tasklet into worker and use only lock_sock() in af_iucv.
CVE-2024-42284:In the Linux kernel, the following vulnerability has been resolved:tipc: Return non-zero value from tipc_udp_addr2str() on errortipc_udp_addr2str() should return non-zero value if the UDP mediaaddress is invalid. Otherwise, a buffer overflow access can occur intipc_media_addr_printf(). Fix this by returning 1 on an invalid UDPmedia address.
CVE-2024-42285:In the Linux kernel, the following vulnerability has been resolved:RDMA/iwcm: Fix a use-after-free related to destroying CM IDsiw_conn_req_handler() associates a new struct rdma_id_private (conn_id) withan existing struct iw_cm_id (cm_id) as follows:        conn_id-&gt;cm_id.iw = cm_id;        cm_id-&gt;context = conn_id;        cm_id-&gt;cm_handler = cma_iw_handler;rdma_destroy_id() frees both the cm_id and the struct rdma_id_private. Makesure that cm_work_handler() does not trigger a use-after-free by onlyfreeing of the struct rdma_id_private after all pending work has finished.
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-38607:In the Linux kernel, the following vulnerability has been resolved:
macintosh/via-macii: Fix &quot;BUG: sleeping function called from invalid context&quot;
The via-macii ADB driver calls request_irq() after disabling hard
interrupts. But disabling interrupts isn't necessary here because the
VIA shift register interrupt was masked during VIA1 initialization.
CVE-2024-37353:In the Linux kernel, the following vulnerability has been resolved:
virtio: delete vq in vp_find_vqs_msix() when request_irq() fails
When request_irq() fails, error path calls vp_del_vqs(). There, as vq is
present in the list, free_irq() is called for the same vector. That
causes following splat:
[    0.414355] Trying to free already-free IRQ 27
[    0.414403] WARNING: CPU: 1 PID: 1 at kernel/irq/manage.c:1899 free_irq+0x1a1/0x2d0
[    0.414510] Modules linked in:
[    0.414540] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 6.9.0-rc4+ #27
[    0.414540] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-1.fc39 04/01/2014
[    0.414540] RIP: 0010:free_irq+0x1a1/0x2d0
[    0.414540] Code: 1e 00 48 83 c4 08 48 89 e8 5b 5d 41 5c 41 5d 41 5e 41 5f c3 cc cc cc cc 90 8b 74 24 04 48 c7 c7 98 80 6c b1 e8 00 c9 f7 ff 90 &lt;0f&gt; 0b 90 90 48 89 ee 4c 89 ef e8 e0 20 b8 00 49 8b 47 40 48 8b 40
[    0.414540] RSP: 0000:ffffb71480013ae0 EFLAGS: 00010086
[    0.414540] RAX: 0000000000000000 RBX: ffffa099c2722000 RCX: 0000000000000000
[    0.414540] RDX: 0000000000000000 RSI: ffffb71480013998 RDI: 0000000000000001
[    0.414540] RBP: 0000000000000246 R08: 00000000ffffdfff R09: 0000000000000001
[    0.414540] R10: 00000000ffffdfff R11: ffffffffb18729c0 R12: ffffa099c1c91760
[    0.414540] R13: ffffa099c1c916a4 R14: ffffa099c1d2f200 R15: ffffa099c1c91600
[    0.414540] FS:  0000000000000000(0000) GS:ffffa099fec40000(0000) knlGS:0000000000000000
[    0.414540] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[    0.414540] CR2: 0000000000000000 CR3: 0000000008e3e001 CR4: 0000000000370ef0
[    0.414540] Call Trace:
[    0.414540]  &lt;TASK&gt;
[    0.414540]  ? __warn+0x80/0x120
[    0.414540]  ? free_irq+0x1a1/0x2d0
[    0.414540]  ? report_bug+0x164/0x190
[    0.414540]  ? handle_bug+0x3b/0x70
[    0.414540]  ? exc_invalid_op+0x17/0x70
[    0.414540]  ? asm_exc_invalid_op+0x1a/0x20
[    0.414540]  ? free_irq+0x1a1/0x2d0
[    0.414540]  vp_del_vqs+0xc1/0x220
[    0.414540]  vp_find_vqs_msix+0x305/0x470
[    0.414540]  vp_find_vqs+0x3e/0x1a0
[    0.414540]  vp_modern_find_vqs+0x1b/0x70
[    0.414540]  init_vqs+0x387/0x600
[    0.414540]  virtnet_probe+0x50a/0xc80
[    0.414540]  virtio_dev_probe+0x1e0/0x2b0
[    0.414540]  really_probe+0xc0/0x2c0
[    0.414540]  ? __pfx___driver_attach+0x10/0x10
[    0.414540]  __driver_probe_device+0x73/0x120
[    0.414540]  driver_probe_device+0x1f/0xe0
[    0.414540]  __driver_attach+0x88/0x180
[    0.414540]  bus_for_each_dev+0x85/0xd0
[    0.414540]  bus_add_driver+0xec/0x1f0
[    0.414540]  driver_register+0x59/0x100
[    0.414540]  ? __pfx_virtio_net_driver_init+0x10/0x10
[    0.414540]  virtio_net_driver_init+0x90/0xb0
[    0.414540]  do_one_initcall+0x58/0x230
[    0.414540]  kernel_init_freeable+0x1a3/0x2d0
[    0.414540]  ? __pfx_kernel_init+0x10/0x10
[    0.414540]  kernel_init+0x1a/0x1c0
[    0.414540]  ret_from_fork+0x31/0x50
[    0.414540]  ? __pfx_kernel_init+0x10/0x10
[    0.414540]  ret_from_fork_asm+0x1a/0x30
[    0.414540]  &lt;/TASK&gt;
Fix this by calling deleting the current vq when request_irq() fails.
CVE-2023-52743:In the Linux kernel, the following vulnerability has been resolved:
ice: Do not use WQ_MEM_RECLAIM flag for workqueue
When both ice and the irdma driver are loaded, a warning in
check_flush_dependency is being triggered. This is due to ice driver
workqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma one
is not.
According to kernel documentation, this flag should be set if the
workqueue will be involved in the kernel's memory reclamation flow.
Since it is not, there is no need for the ice driver's WQ to have this
flag set so remove it.
Example trace:
[  +0.000004] workqueue: WQ_MEM_RECLAIM ice:ice_service_task [ice] is flushing !WQ_MEM_RECLAIM infiniband:0x0
[  +0.000139] WARNING: CPU: 0 PID: 728 at kernel/workqueue.c:2632 check_flush_dependency+0x178/0x1a0
[  +0.000011] Modules linked in: bonding tls xt_CHECKSUM xt_MASQUERADE xt_conntrack ipt_REJECT nf_reject_ipv4 nft_compat nft_cha
in_nat nf_nat nf_conntrack nf_defrag_ipv6 nf_defrag_ipv4 nf_tables nfnetlink bridge stp llc rfkill vfat fat intel_rapl_msr intel
_rapl_common isst_if_common skx_edac nfit libnvdimm x86_pkg_temp_thermal intel_powerclamp coretemp kvm_intel kvm irqbypass crct1
0dif_pclmul crc32_pclmul ghash_clmulni_intel rapl intel_cstate rpcrdma sunrpc rdma_ucm ib_srpt ib_isert iscsi_target_mod target_
core_mod ib_iser libiscsi scsi_transport_iscsi rdma_cm ib_cm iw_cm iTCO_wdt iTCO_vendor_support ipmi_ssif irdma mei_me ib_uverbs
ib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meter
acpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit liba
ta dca wmi dm_mirror dm_region_hash dm_log dm_mod ipmi_devintf ipmi_msghandler fuse
[  +0.000161]  [last unloaded: bonding]
[  +0.000006] CPU: 0 PID: 728 Comm: kworker/0:2 Tainted: G S                 6.2.0-rc2_next-queue-13jan-00458-gc20aabd57164 #1
[  +0.000006] Hardware name: Intel Corporation S2600WFT/S2600WFT, BIOS SE5C620.86B.02.01.0010.010620200716 01/06/2020
[  +0.000003] Workqueue: ice ice_service_task [ice]
[  +0.000127] RIP: 0010:check_flush_dependency+0x178/0x1a0
[  +0.000005] Code: 89 8e 02 01 e8 49 3d 40 00 49 8b 55 18 48 8d 8d d0 00 00 00 48 8d b3 d0 00 00 00 4d 89 e0 48 c7 c7 e0 3b 08
9f e8 bb d3 07 01 &lt;0f&gt; 0b e9 be fe ff ff 80 3d 24 89 8e 02 00 0f 85 6b ff ff ff e9 06
[  +0.000004] RSP: 0018:ffff88810a39f990 EFLAGS: 00010282
[  +0.000005] RAX: 0000000000000000 RBX: ffff888141bc2400 RCX: 0000000000000000
[  +0.000004] RDX: 0000000000000001 RSI: dffffc0000000000 RDI: ffffffffa1213a80
[  +0.000003] RBP: ffff888194bf3400 R08: ffffed117b306112 R09: ffffed117b306112
[  +0.000003] R10: ffff888bd983088b R11: ffffed117b306111 R12: 0000000000000000
[  +0.000003] R13: ffff888111f84d00 R14: ffff88810a3943ac R15: ffff888194bf3400
[  +0.000004] FS:  0000000000000000(0000) GS:ffff888bd9800000(0000) knlGS:0000000000000000
[  +0.000003] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  +0.000003] CR2: 000056035b208b60 CR3: 000000017795e005 CR4: 00000000007706f0
[  +0.000003] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[  +0.000003] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[  +0.000002] PKRU: 55555554
[  +0.000003] Call Trace:
[  +0.000002]  &lt;TASK&gt;
[  +0.000003]  __flush_workqueue+0x203/0x840
[  +0.000006]  ? mutex_unlock+0x84/0xd0
[  +0.000008]  ? __pfx_mutex_unlock+0x10/0x10
[  +0.000004]  ? __pfx___flush_workqueue+0x10/0x10
[  +0.000006]  ? mutex_lock+0xa3/0xf0
[  +0.000005]  ib_cache_cleanup_one+0x39/0x190 [ib_core]
[  +0.000174]  __ib_unregister_device+0x84/0xf0 [ib_core]
[  +0.000094]  ib_unregister_device+0x25/0x30 [ib_core]
[  +0.000093]  irdma_ib_unregister_device+0x97/0xc0 [irdma]
[  +0.000064]  ? __pfx_irdma_ib_unregister_device+0x10/0x10 [irdma]
[  +0.000059]  ? up_write+0x5c/0x90
[  +0.000005]  irdma_remove+0x36/0x90 [irdma]
[  +0.000062]  auxiliary_bus_remove+0x32/0x50
[  +0.000007]  device_r
---truncated---
CVE-2024-38582:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential hang in nilfs_detach_log_writer()
Syzbot has reported a potential hang in nilfs_detach_log_writer() called
during nilfs2 unmount.
Analysis revealed that this is because nilfs_segctor_sync(), which
synchronizes with the log writer thread, can be called after
nilfs_segctor_destroy() terminates that thread, as shown in the call trace
below:
nilfs_detach_log_writer
  nilfs_segctor_destroy
    nilfs_segctor_kill_thread  --&gt; Shut down log writer thread
    flush_work
      nilfs_iput_work_func
        nilfs_dispose_list
          iput
            nilfs_evict_inode
              nilfs_transaction_commit
                nilfs_construct_segment (if inode needs sync)
                  nilfs_segctor_sync  --&gt; Attempt to synchronize with
                                          log writer thread
                           *** DEADLOCK ***
Fix this issue by changing nilfs_segctor_sync() so that the log writer
thread returns normally without synchronizing after it terminates, and by
forcing tasks that are already waiting to complete once after the thread
terminates.
The skipped inode metadata flushout will then be processed together in the
subsequent cleanup work in nilfs_segctor_destroy().
CVE-2024-39467:In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on i_xattr_nid in sanity_check_inode()
syzbot reports a kernel bug as below:
F2FS-fs (loop0): Mounted with checkpoint version = 48b305e4
==================================================================
BUG: KASAN: slab-out-of-bounds in f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
BUG: KASAN: slab-out-of-bounds in current_nat_addr fs/f2fs/node.h:213 [inline]
BUG: KASAN: slab-out-of-bounds in f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076
CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-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
 f2fs_test_bit fs/f2fs/f2fs.h:2933 [inline]
 current_nat_addr fs/f2fs/node.h:213 [inline]
 f2fs_get_node_info+0xece/0x1200 fs/f2fs/node.c:600
 f2fs_xattr_fiemap fs/f2fs/data.c:1848 [inline]
 f2fs_fiemap+0x55d/0x1ee0 fs/f2fs/data.c:1925
 ioctl_fiemap fs/ioctl.c:220 [inline]
 do_vfs_ioctl+0x1c07/0x2e50 fs/ioctl.c:838
 __do_sys_ioctl fs/ioctl.c:902 [inline]
 __se_sys_ioctl+0x81/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
The root cause is we missed to do sanity check on i_xattr_nid during
f2fs_iget(), so that in fiemap() path, current_nat_addr() will access
nat_bitmap w/ offset from invalid i_xattr_nid, result in triggering
kasan bug report, fix it.
CVE-2024-38586:In the Linux kernel, the following vulnerability has been resolved:
r8169: Fix possible ring buffer corruption on fragmented Tx packets.
An issue was found on the RTL8125b when transmitting small fragmented
packets, whereby invalid entries were inserted into the transmit ring
buffer, subsequently leading to calls to dma_unmap_single() with a null
address.
This was caused by rtl8169_start_xmit() not noticing changes to nr_frags
which may occur when small packets are padded (to work around hardware
quirks) in rtl8169_tso_csum_v2().
To fix this, postpone inspecting nr_frags until after any padding has been
applied.
CVE-2024-36489:In the Linux kernel, the following vulnerability has been resolved:
tls: fix missing memory barrier in tls_init
In tls_init(), a write memory barrier is missing, and store-store
reordering may cause NULL dereference in tls_{setsockopt,getsockopt}.
CPU0                               CPU1
-----                              -----
// In tls_init()
// In tls_ctx_create()
ctx = kzalloc()
ctx-&gt;sk_proto = READ_ONCE(sk-&gt;sk_prot) -(1)
// In update_sk_prot()
WRITE_ONCE(sk-&gt;sk_prot, tls_prots)     -(2)
                                   // In sock_common_setsockopt()
                                   READ_ONCE(sk-&gt;sk_prot)-&gt;setsockopt()
                                   // In tls_{setsockopt,getsockopt}()
                                   ctx-&gt;sk_proto-&gt;setsockopt()    -(3)
In the above scenario, when (1) and (2) are reordered, (3) can observe
the NULL value of ctx-&gt;sk_proto, causing NULL dereference.
To fix it, we rely on rcu_assign_pointer() which implies the release
barrier semantic. By moving rcu_assign_pointer() after ctx-&gt;sk_proto is
initialized, we can ensure that ctx-&gt;sk_proto are visible when
changing sk-&gt;sk_prot.
CVE-2024-38579:In the Linux kernel, the following vulnerability has been resolved:
crypto: bcm - Fix pointer arithmetic
In spu2_dump_omd() value of ptr is increased by ciph_key_len
instead of hash_iv_len which could lead to going beyond the
buffer boundaries.
Fix this bug by changing ciph_key_len to hash_iv_len.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-38554:In the Linux kernel, the following vulnerability has been resolved:
ax25: Fix reference count leak issue of net_device
There is a reference count leak issue of the object &quot;net_device&quot; in
ax25_dev_device_down(). When the ax25 device is shutting down, the
ax25_dev_device_down() drops the reference count of net_device one
or zero times depending on if we goto unlock_put or not, which will
cause memory leak.
In order to solve the above issue, decrease the reference count of
net_device after dev-&gt;ax25_ptr is set to null.
CVE-2024-38546:In the Linux kernel, the following vulnerability has been resolved:drm: vc4: Fix possible null pointer dereferenceIn vc4_hdmi_audio_init() of_get_address() may returnNULL which is later dereferenced. Fix this bug by adding NULL check.Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-38637:In the Linux kernel, the following vulnerability has been resolved:
greybus: lights: check return of get_channel_from_mode
If channel for the given node is not found we return null from
get_channel_from_mode. Make sure we validate the return pointer
before using it in two of the missing places.
This was originally reported in [0]:
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[0] https://lore.kernel.org/all/20240301190425.120605-1-m.lobanov@rosalinux.ru
CVE-2024-38780:In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don t enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 ( dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context ) by error replaced spin_unlock_irqrestore() withspin_unlock_irq() for both sync_debugfs_show() and sync_print_obj() despitesync_print_obj() is called from sync_debugfs_show(), lockdep complainsinconsistent lock state warning.Use plain spin_{lock,unlock}() for sync_print_obj(), forsync_debugfs_show() is already using spin_{lock,unlock}_irq().
CVE-2024-38602:In the Linux kernel, the following vulnerability has been resolved:
ax25: Fix reference count leak issues of ax25_dev
The ax25_addr_ax25dev() and ax25_dev_device_down() exist a reference
count leak issue of the object &quot;ax25_dev&quot;.
Memory leak issue in ax25_addr_ax25dev():
The reference count of the object &quot;ax25_dev&quot; can be increased multiple
times in ax25_addr_ax25dev(). This will cause a memory leak.
Memory leak issues in ax25_dev_device_down():
The reference count of ax25_dev is set to 1 in ax25_dev_device_up() and
then increase the reference count when ax25_dev is added to ax25_dev_list.
As a result, the reference count of ax25_dev is 2. But when the device is
shutting down. The ax25_dev_device_down() drops the reference count once
or twice depending on if we goto unlock_put or not, which will cause
memory leak.
As for the issue of ax25_addr_ax25dev(), it is impossible for one pointer
to be on a list twice. So add a break in ax25_addr_ax25dev(). As for the
issue of ax25_dev_device_down(), increase the reference count of ax25_dev
once in ax25_dev_device_up() and decrease the reference count of ax25_dev
after it is removed from the ax25_dev_list.
CVE-2022-48765:In the Linux kernel, the following vulnerability has been resolved:
KVM: LAPIC: Also cancel preemption timer during SET_LAPIC
The below warning is splatting during guest reboot.
  ------------[ cut here ]------------
  WARNING: CPU: 0 PID: 1931 at arch/x86/kvm/x86.c:10322 kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  CPU: 0 PID: 1931 Comm: qemu-system-x86 Tainted: G          I       5.17.0-rc1+ #5
  RIP: 0010:kvm_arch_vcpu_ioctl_run+0x874/0x880 [kvm]
  Call Trace:
   &lt;TASK&gt;
   kvm_vcpu_ioctl+0x279/0x710 [kvm]
   __x64_sys_ioctl+0x83/0xb0
   do_syscall_64+0x3b/0xc0
   entry_SYSCALL_64_after_hwframe+0x44/0xae
  RIP: 0033:0x7fd39797350b
This can be triggered by not exposing tsc-deadline mode and doing a reboot in
the guest. The lapic_shutdown() function which is called in sys_reboot path
will not disarm the flying timer, it just masks LVTT. lapic_shutdown() clears
APIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-mode
switch between tsc-deadline and oneshot/periodic, which can result in preemption
timer be cancelled in apic_update_lvtt(). However, We can't depend on this when
not exposing tsc-deadline mode and oneshot/periodic modes emulated by preemption
timer. Qemu will synchronise states around reset, let's cancel preemption timer
under KVM_SET_LAPIC.
CVE-2024-38603:In the Linux kernel, the following vulnerability has been resolved:
drivers/perf: hisi: hns3: Actually use devm_add_action_or_reset()
pci_alloc_irq_vectors() allocates an irq vector. When devm_add_action()
fails, the irq vector is not freed, which leads to a memory leak.
Replace the devm_add_action with devm_add_action_or_reset to ensure
the irq vector can be destroyed when it fails.
CVE-2024-39301:In the Linux kernel, the following vulnerability has been resolved:
net/9p: fix uninit-value in p9_client_rpc()
Syzbot with the help of KMSAN reported the following error:
BUG: KMSAN: uninit-value in trace_9p_client_res include/trace/events/9p.h:146 [inline]
BUG: KMSAN: uninit-value in p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
 trace_9p_client_res include/trace/events/9p.h:146 [inline]
 p9_client_rpc+0x1314/0x1340 net/9p/client.c:754
 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
 legacy_get_tree+0x114/0x290 fs/fs_context.c:662
 vfs_get_tree+0xa7/0x570 fs/super.c:1797
 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
 path_mount+0x742/0x1f20 fs/namespace.c:3679
 do_mount fs/namespace.c:3692 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x725/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
Uninit was created at:
 __alloc_pages+0x9d6/0xe70 mm/page_alloc.c:4598
 __alloc_pages_node include/linux/gfp.h:238 [inline]
 alloc_pages_node include/linux/gfp.h:261 [inline]
 alloc_slab_page mm/slub.c:2175 [inline]
 allocate_slab mm/slub.c:2338 [inline]
 new_slab+0x2de/0x1400 mm/slub.c:2391
 ___slab_alloc+0x1184/0x33d0 mm/slub.c:3525
 __slab_alloc mm/slub.c:3610 [inline]
 __slab_alloc_node mm/slub.c:3663 [inline]
 slab_alloc_node mm/slub.c:3835 [inline]
 kmem_cache_alloc+0x6d3/0xbe0 mm/slub.c:3852
 p9_tag_alloc net/9p/client.c:278 [inline]
 p9_client_prepare_req+0x20a/0x1770 net/9p/client.c:641
 p9_client_rpc+0x27e/0x1340 net/9p/client.c:688
 p9_client_create+0x1551/0x1ff0 net/9p/client.c:1031
 v9fs_session_init+0x1b9/0x28e0 fs/9p/v9fs.c:410
 v9fs_mount+0xe2/0x12b0 fs/9p/vfs_super.c:122
 legacy_get_tree+0x114/0x290 fs/fs_context.c:662
 vfs_get_tree+0xa7/0x570 fs/super.c:1797
 do_new_mount+0x71f/0x15e0 fs/namespace.c:3352
 path_mount+0x742/0x1f20 fs/namespace.c:3679
 do_mount fs/namespace.c:3692 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x725/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x150 fs/namespace.c:3875
 do_syscall_64+0xd5/0x1f0
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
If p9_check_errors() fails early in p9_client_rpc(), req-&gt;rc.tag
will not be properly initialized. However, trace_9p_client_res()
ends up trying to print it out anyway before p9_client_rpc()
finishes.
Fix this issue by assigning default values to p9_fcall fields
such as 'tag' and (just in case KMSAN unearths something new) 'id'
during the tag allocation stage.
CVE-2024-38621:In the Linux kernel, the following vulnerability has been resolved:
media: stk1160: fix bounds checking in stk1160_copy_video()
The subtract in this condition is reversed.  The -&gt;length is the length
of the buffer.  The -&gt;bytesused is how many bytes we have copied thus
far.  When the condition is reversed that means the result of the
subtraction is always negative but since it's unsigned then the result
is a very high positive value.  That means the overflow check is never
true.
Additionally, the -&gt;bytesused doesn't actually work for this purpose
because we're not writing to &quot;buf-&gt;mem + buf-&gt;bytesused&quot;.  Instead, the
math to calculate the destination where we are writing is a bit
involved.  You calculate the number of full lines already written,
multiply by two, skip a line if necessary so that we start on an odd
numbered line, and add the offset into the line.
To fix this buffer overflow, just take the actual destination where we
are writing, if the offset is already out of bounds print an error and
return.  Otherwise, write up to buf-&gt;length bytes.
CVE-2024-38547:In the Linux kernel, the following vulnerability has been resolved:
media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binaries
The allocation failure of mycs-&gt;yuv_scaler_binary in load_video_binaries()
is followed with a dereference of mycs-&gt;yuv_scaler_binary after the
following call chain:
sh_css_pipe_load_binaries()
  |-&gt; load_video_binaries(mycs-&gt;yuv_scaler_binary == NULL)
  |
  |-&gt; sh_css_pipe_unload_binaries()
        |-&gt; unload_video_binaries()
In unload_video_binaries(), it calls to ia_css_binary_unload with argument
&amp;pipe-&gt;pipe_settings.video.yuv_scaler_binary[i], which refers to the
same memory slot as mycs-&gt;yuv_scaler_binary. Thus, a null-pointer
dereference is triggered.
CVE-2024-39277:In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: benchmark: handle NUMA_NO_NODE correctly
cpumask_of_node() can be called for NUMA_NO_NODE inside do_map_benchmark()
resulting in the following sanitizer report:
UBSAN: array-index-out-of-bounds in ./arch/x86/include/asm/topology.h:72:28
index -1 is out of range for type 'cpumask [64][1]'
CPU: 1 PID: 990 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #29
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
 &lt;TASK&gt;
dump_stack_lvl (lib/dump_stack.c:117)
ubsan_epilogue (lib/ubsan.c:232)
__ubsan_handle_out_of_bounds (lib/ubsan.c:429)
cpumask_of_node (arch/x86/include/asm/topology.h:72) [inline]
do_map_benchmark (kernel/dma/map_benchmark.c:104)
map_benchmark_ioctl (kernel/dma/map_benchmark.c:246)
full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)
__x64_sys_ioctl (fs/ioctl.c:890)
do_syscall_64 (arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Use cpumask_of_node() in place when binding a kernel thread to a cpuset
of a particular node.
Note that the provided node id is checked inside map_benchmark_ioctl().
It's just a NUMA_NO_NODE case which is not handled properly later.
Found by Linux Verification Center (linuxtesting.org).
CVE-2024-39469:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errors
The error handling in nilfs_empty_dir() when a directory folio/page read
fails is incorrect, as in the old ext2 implementation, and if the
folio/page cannot be read or nilfs_check_folio() fails, it will falsely
determine the directory as empty and corrupt the file system.
In addition, since nilfs_empty_dir() does not immediately return on a
failed folio/page read, but continues to loop, this can cause a long loop
with I/O if i_size of the directory's inode is also corrupted, causing the
log writer thread to wait and hang, as reported by syzbot.
Fix these issues by making nilfs_empty_dir() immediately return a false
value (0) if it fails to get a directory folio/page.
CVE-2024-26816:In the Linux kernel, the following vulnerability has been resolved: x86, relocs: Ignore relocations in .notes section When building with CONFIG_XEN_PV=y, .text symbols are emitted into the .notes section so that Xen can find the &quot;startup_xen&quot; entry point. This information is used prior to booting the kernel, so relocations are not useful. In fact, performing relocations against the .notes section means that the KASLR base is exposed since /sys/kernel/notes is world-readable. To avoid leaking the KASLR base without breaking unprivileged tools that are expecting to read /sys/kernel/notes, skip performing relocations in the .notes section. The values readable in .notes are then identical to those found in System.map.
CVE-2024-34027:In the Linux kernel, the following vulnerability has been resolved:
f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
It needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lock
to avoid racing with checkpoint, otherwise, filesystem metadata including
blkaddr in dnode, inode fields and .total_valid_block_count may be
corrupted after SPO case.
CVE-2022-48733:In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix use-after-free after failure to create a snapshot
At ioctl.c:create_snapshot(), we allocate a pending snapshot structure and
then attach it to the transaction's list of pending snapshots. After that
we call btrfs_commit_transaction(), and if that returns an error we jump
to 'fail' label, where we kfree() the pending snapshot structure. This can
result in a later use-after-free of the pending snapshot:
1) We allocated the pending snapshot and added it to the transaction's
   list of pending snapshots;
2) We call btrfs_commit_transaction(), and it fails either at the first
   call to btrfs_run_delayed_refs() or btrfs_start_dirty_block_groups().
   In both cases, we don't abort the transaction and we release our
   transaction handle. We jump to the 'fail' label and free the pending
   snapshot structure. We return with the pending snapshot still in the
   transaction's list;
3) Another task commits the transaction. This time there's no error at
   all, and then during the transaction commit it accesses a pointer
   to the pending snapshot structure that the snapshot creation task
   has already freed, resulting in a user-after-free.
This issue could actually be detected by smatch, which produced the
following warning:
  fs/btrfs/ioctl.c:843 create_snapshot() warn: '&amp;pending_snapshot-&gt;list' not removed from list
So fix this by not having the snapshot creation ioctl directly add the
pending snapshot to the transaction's list. Instead add the pending
snapshot to the transaction handle, and then at btrfs_commit_transaction()
we add the snapshot to the list only when we can guarantee that any error
returned after that point will result in a transaction abort, in which
case the ioctl code can safely free the pending snapshot and no one can
access it anymore.
CVE-2024-38558:In the Linux kernel, the following vulnerability has been resolved:
net: openvswitch: fix overwriting ct original tuple for ICMPv6
OVS_PACKET_CMD_EXECUTE has 3 main attributes:
 - OVS_PACKET_ATTR_KEY - Packet metadata in a netlink format.
 - OVS_PACKET_ATTR_PACKET - Binary packet content.
 - OVS_PACKET_ATTR_ACTIONS - Actions to execute on the packet.
OVS_PACKET_ATTR_KEY is parsed first to populate sw_flow_key structure
with the metadata like conntrack state, input port, recirculation id,
etc.  Then the packet itself gets parsed to populate the rest of the
keys from the packet headers.
Whenever the packet parsing code starts parsing the ICMPv6 header, it
first zeroes out fields in the key corresponding to Neighbor Discovery
information even if it is not an ND packet.
It is an 'ipv6.nd' field.  However, the 'ipv6' is a union that shares
the space between 'nd' and 'ct_orig' that holds the original tuple
conntrack metadata parsed from the OVS_PACKET_ATTR_KEY.
ND packets should not normally have conntrack state, so it's fine to
share the space, but normal ICMPv6 Echo packets or maybe other types of
ICMPv6 can have the state attached and it should not be overwritten.
The issue results in all but the last 4 bytes of the destination
address being wiped from the original conntrack tuple leading to
incorrect packet matching and potentially executing wrong actions
in case this packet recirculates within the datapath or goes back
to userspace.
ND fields should not be accessed in non-ND packets, so not clearing
them should be fine.  Executing memset() only for actual ND packets to
avoid the issue.
Initializing the whole thing before parsing is needed because ND packet
may not contain all the options.
The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn't
affect packets entering OVS datapath from network interfaces, because
in this case CT metadata is populated from skb after the packet is
already parsed.
CVE-2023-4458:This vulnerability allows remote attackers to disclose sensitive information on affected installations of Linux Kernel. Authentication may or may not be required to exploit this vulnerability, depending upon configuration. Furthermore, only systems with ksmbd enabled are vulnerable.
CVE-2024-38548:In the Linux kernel, the following vulnerability has been resolved:
drm: bridge: cdns-mhdp8546: Fix possible null pointer dereference
In cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() is
assigned to mhdp_state-&gt;current_mode, and there is a dereference of it in
drm_mode_set_name(), which will lead to a NULL pointer dereference on
failure of drm_mode_duplicate().
Fix this bug add a check of mhdp_state-&gt;current_mode.
CVE-2024-36478:In the Linux kernel, the following vulnerability has been resolved:
null_blk: fix null-ptr-dereference while configuring 'power' and 'submit_queues'
Writing 'power' and 'submit_queues' concurrently will trigger kernel
panic:
Test script:
modprobe null_blk nr_devices=0
mkdir -p /sys/kernel/config/nullb/nullb0
while true; do echo 1 &gt; submit_queues; echo 4 &gt; submit_queues; done &amp;
while true; do echo 1 &gt; power; echo 0 &gt; power; done
Test result:
BUG: kernel NULL pointer dereference, address: 0000000000000148
Oops: 0000 [#1] PREEMPT SMP
RIP: 0010:__lock_acquire+0x41d/0x28f0
Call Trace:
 &lt;TASK&gt;
 lock_acquire+0x121/0x450
 down_write+0x5f/0x1d0
 simple_recursive_removal+0x12f/0x5c0
 blk_mq_debugfs_unregister_hctxs+0x7c/0x100
 blk_mq_update_nr_hw_queues+0x4a3/0x720
 nullb_update_nr_hw_queues+0x71/0xf0 [null_blk]
 nullb_device_submit_queues_store+0x79/0xf0 [null_blk]
 configfs_write_iter+0x119/0x1e0
 vfs_write+0x326/0x730
 ksys_write+0x74/0x150
This is because del_gendisk() can concurrent with
blk_mq_update_nr_hw_queues():
nullb_device_power_store	nullb_apply_submit_queues
 null_del_dev
 del_gendisk
				 nullb_update_nr_hw_queues
				  if (!dev-&gt;nullb)
				  // still set while gendisk is deleted
				   return 0
				  blk_mq_update_nr_hw_queues
 dev-&gt;nullb = NULL
Fix this problem by resuing the global mutex to protect
nullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.
CVE-2024-39480:In the Linux kernel, the following vulnerability has been resolved:kdb: Fix buffer overflow during tab-completeCurrently, when the user attempts symbol completion with the Tab key, kdbwill use strncpy() to insert the completed symbol into the command buffer.Unfortunately it passes the size of the source buffer rather than thedestination to strncpy() with predictably horrible results. Most obviouslyif the command buffer is already full but cp, the cursor position, is inthe middle of the buffer, then we will write past the end of the suppliedbuffer.Fix this by replacing the dubious strncpy() calls with memmove()/memcpy()calls plus explicit boundary checks to make sure we have enough spacebefore we start moving characters around.
CVE-2024-38540:In the Linux kernel, the following vulnerability has been resolved:
bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwq
Undefined behavior is triggered when bnxt_qplib_alloc_init_hwq is called
with hwq_attr-&gt;aux_depth != 0 and hwq_attr-&gt;aux_stride == 0.
In that case, &quot;roundup_pow_of_two(hwq_attr-&gt;aux_stride)&quot; gets called.
roundup_pow_of_two is documented as undefined for 0.
Fix it in the one caller that had this combination.
The undefined behavior was detected by UBSAN:
  UBSAN: shift-out-of-bounds in ./include/linux/log2.h:57:13
  shift exponent 64 is too large for 64-bit type 'long unsigned int'
  CPU: 24 PID: 1075 Comm: (udev-worker) Not tainted 6.9.0-rc6+ #4
  Hardware name: Abacus electric, s.r.o. - servis@abacus.cz Super Server/H12SSW-iN, BIOS 2.7 10/25/2023
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x5d/0x80
   ubsan_epilogue+0x5/0x30
   __ubsan_handle_shift_out_of_bounds.cold+0x61/0xec
   __roundup_pow_of_two+0x25/0x35 [bnxt_re]
   bnxt_qplib_alloc_init_hwq+0xa1/0x470 [bnxt_re]
   bnxt_qplib_create_qp+0x19e/0x840 [bnxt_re]
   bnxt_re_create_qp+0x9b1/0xcd0 [bnxt_re]
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __kmalloc+0x1b6/0x4f0
   ? create_qp.part.0+0x128/0x1c0 [ib_core]
   ? __pfx_bnxt_re_create_qp+0x10/0x10 [bnxt_re]
   create_qp.part.0+0x128/0x1c0 [ib_core]
   ib_create_qp_kernel+0x50/0xd0 [ib_core]
   create_mad_qp+0x8e/0xe0 [ib_core]
   ? __pfx_qp_event_handler+0x10/0x10 [ib_core]
   ib_mad_init_device+0x2be/0x680 [ib_core]
   add_client_context+0x10d/0x1a0 [ib_core]
   enable_device_and_get+0xe0/0x1d0 [ib_core]
   ib_register_device+0x53c/0x630 [ib_core]
   ? srso_alias_return_thunk+0x5/0xfbef5
   bnxt_re_probe+0xbd8/0xe50 [bnxt_re]
   ? __pfx_bnxt_re_probe+0x10/0x10 [bnxt_re]
   auxiliary_bus_probe+0x49/0x80
   ? driver_sysfs_add+0x57/0xc0
   really_probe+0xde/0x340
   ? pm_runtime_barrier+0x54/0x90
   ? __pfx___driver_attach+0x10/0x10
   __driver_probe_device+0x78/0x110
   driver_probe_device+0x1f/0xa0
   __driver_attach+0xba/0x1c0
   bus_for_each_dev+0x8f/0xe0
   bus_add_driver+0x146/0x220
   driver_register+0x72/0xd0
   __auxiliary_driver_register+0x6e/0xd0
   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
   bnxt_re_mod_init+0x3e/0xff0 [bnxt_re]
   ? __pfx_bnxt_re_mod_init+0x10/0x10 [bnxt_re]
   do_one_initcall+0x5b/0x310
   do_init_module+0x90/0x250
   init_module_from_file+0x86/0xc0
   idempotent_init_module+0x121/0x2b0
   __x64_sys_finit_module+0x5e/0xb0
   do_syscall_64+0x82/0x160
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? syscall_exit_to_user_mode_prepare+0x149/0x170
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? syscall_exit_to_user_mode+0x75/0x230
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? do_syscall_64+0x8e/0x160
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? __count_memcg_events+0x69/0x100
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? count_memcg_events.constprop.0+0x1a/0x30
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? handle_mm_fault+0x1f0/0x300
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? do_user_addr_fault+0x34e/0x640
   ? srso_alias_return_thunk+0x5/0xfbef5
   ? srso_alias_return_thunk+0x5/0xfbef5
   entry_SYSCALL_64_after_hwframe+0x76/0x7e
  RIP: 0033:0x7f4e5132821d
  Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d e3 db 0c 00 f7 d8 64 89 01 48
  RSP: 002b:00007ffca9c906a8 EFLAGS: 00000246 ORIG_RAX: 0000000000000139
  RAX: ffffffffffffffda RBX: 0000563ec8a8f130 RCX: 00007f4e5132821d
  RDX: 0000000000000000 RSI: 00007f4e518fa07d RDI: 000000000000003b
  RBP: 00007ffca9c90760 R08: 00007f4e513f6b20 R09: 00007ffca9c906f0
  R10: 0000563ec8a8faa0 R11: 0000000000000246 R12: 00007f4e518fa07d
  R13: 0000000000020000 R14: 0000563ec8409e90 R15: 0000563ec8a8fa60
   &lt;/TASK&gt;
  ---[ end trace ]---
CVE-2024-38615:In the Linux kernel, the following vulnerability has been resolved:
cpufreq: exit() callback is optional
The exit() callback is optional and shouldn't be called without checking
a valid pointer first.
Also, we must clear freq_table pointer even if the exit() callback isn't
present.
CVE-2023-52757:In the Linux kernel, the following vulnerability has been resolved:
smb: client: fix potential deadlock when releasing mids
All release_mid() callers seem to hold a reference of @mid so there is
no need to call kref_put(&amp;mid-&gt;refcount, __release_mid) under
@server-&gt;mid_lock spinlock.  If they don't, then an use-after-free bug
would have occurred anyways.
By getting rid of such spinlock also fixes a potential deadlock as
shown below
CPU 0                                CPU 1
------------------------------------------------------------------
cifs_demultiplex_thread()            cifs_debug_data_proc_show()
 release_mid()
  spin_lock(&amp;server-&gt;mid_lock);
                                     spin_lock(&amp;cifs_tcp_ses_lock)
				      spin_lock(&amp;server-&gt;mid_lock)
  __release_mid()
   smb2_find_smb_tcon()
    spin_lock(&amp;cifs_tcp_ses_lock) *deadlock*
CVE-2023-52755:In the Linux kernel, the following vulnerability has been resolved:
ksmbd: fix slab out of bounds write in smb_inherit_dacl()
slab out-of-bounds write is caused by that offsets is bigger than pntsd
allocation size. This patch add the check to validate 3 offsets using
allocation size.
CVE-2024-39484:In the Linux kernel, the following vulnerability has been resolved:
mmc: davinci: Don't strip remove function when driver is builtin
Using __exit for the remove function results in the remove callback being
discarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.
using sysfs or hotplug), the driver is just removed without the cleanup
being performed. This results in resource leaks. Fix it by compiling in the
remove callback unconditionally.
This also fixes a W=1 modpost warning:
WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch in
reference: davinci_mmcsd_driver+0x10 (section: .data) -&gt;
davinci_mmcsd_remove (section: .exit.text)
CVE-2024-39472:In the Linux kernel, the following vulnerability has been resolved:xfs: fix log recovery buffer allocation for the legacy h_size fixupCommit a70f9fe52daa ( xfs: detect and handle invalid iclog size set bymkfs ) added a fixup for incorrect h_size values used for the initialumount record in old xfsprogs versions.  Later commit 0c771b99d6c9( xfs: clean up calculation of LR header blocks ) cleaned up the logreover buffer calculation, but stoped using the fixed up h_size valueto size the log recovery buffer, which can lead to an out of boundsaccess when the incorrect h_size does not come from the old mkfstool, but a fuzzer.Fix this by open coding xlog_logrec_hblks and taking the fixed h_sizeinto account for this calculation.
CVE-2024-38598:In the Linux kernel, the following vulnerability has been resolved:
md: fix resync softlockup when bitmap size is less than array size
Is is reported that for dm-raid10, lvextend + lvchange --syncaction will
trigger following softlockup:
kernel:watchdog: BUG: soft lockup - CPU#3 stuck for 26s! [mdX_resync:6976]
CPU: 7 PID: 3588 Comm: mdX_resync Kdump: loaded Not tainted 6.9.0-rc4-next-20240419 #1
RIP: 0010:_raw_spin_unlock_irq+0x13/0x30
Call Trace:
 &lt;TASK&gt;
 md_bitmap_start_sync+0x6b/0xf0
 raid10_sync_request+0x25c/0x1b40 [raid10]
 md_do_sync+0x64b/0x1020
 md_thread+0xa7/0x170
 kthread+0xcf/0x100
 ret_from_fork+0x30/0x50
 ret_from_fork_asm+0x1a/0x30
And the detailed process is as follows:
md_do_sync
 j = mddev-&gt;resync_min
 while (j &lt; max_sectors)
  sectors = raid10_sync_request(mddev, j, &amp;skipped)
   if (!md_bitmap_start_sync(..., &amp;sync_blocks))
    // md_bitmap_start_sync set sync_blocks to 0
    return sync_blocks + sectors_skippe;
  // sectors = 0;
  j += sectors;
  // j never change
Root cause is that commit 301867b1c168 (&quot;md/raid10: check
slab-out-of-bounds in md_bitmap_get_counter&quot;) return early from
md_bitmap_get_counter(), without setting returned blocks.
Fix this problem by always set returned blocks from
md_bitmap_get_counter&quot;(), as it used to be.
Noted that this patch just fix the softlockup problem in kernel, the
case that bitmap size doesn't match array size still need to be fixed.
CVE-2024-35899:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: flush pending destroy work before exit_net release
Similar to 2c9f0293280e (&quot;netfilter: nf_tables: flush pending destroy
work before netlink notifier&quot;) to address a race between exit_net and
the destroy workqueue.
The trace below shows an element to be released via destroy workqueue
while exit_net path (triggered via module removal) has already released
the set that is used in such transaction.
[ 1360.547789] BUG: KASAN: slab-use-after-free in nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.547861] Read of size 8 at addr ffff888140500cc0 by task kworker/4:1/152465
[ 1360.547870] CPU: 4 PID: 152465 Comm: kworker/4:1 Not tainted 6.8.0+ #359
[ 1360.547882] Workqueue: events nf_tables_trans_destroy_work [nf_tables]
[ 1360.547984] Call Trace:
[ 1360.547991]  &lt;TASK&gt;
[ 1360.547998]  dump_stack_lvl+0x53/0x70
[ 1360.548014]  print_report+0xc4/0x610
[ 1360.548026]  ? __virt_addr_valid+0xba/0x160
[ 1360.548040]  ? __pfx__raw_spin_lock_irqsave+0x10/0x10
[ 1360.548054]  ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.548176]  kasan_report+0xae/0xe0
[ 1360.548189]  ? nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.548312]  nf_tables_trans_destroy_work+0x3f5/0x590 [nf_tables]
[ 1360.548447]  ? __pfx_nf_tables_trans_destroy_work+0x10/0x10 [nf_tables]
[ 1360.548577]  ? _raw_spin_unlock_irq+0x18/0x30
[ 1360.548591]  process_one_work+0x2f1/0x670
[ 1360.548610]  worker_thread+0x4d3/0x760
[ 1360.548627]  ? __pfx_worker_thread+0x10/0x10
[ 1360.548640]  kthread+0x16b/0x1b0
[ 1360.548653]  ? __pfx_kthread+0x10/0x10
[ 1360.548665]  ret_from_fork+0x2f/0x50
[ 1360.548679]  ? __pfx_kthread+0x10/0x10
[ 1360.548690]  ret_from_fork_asm+0x1a/0x30
[ 1360.548707]  &lt;/TASK&gt;
[ 1360.548719] Allocated by task 192061:
[ 1360.548726]  kasan_save_stack+0x20/0x40
[ 1360.548739]  kasan_save_track+0x14/0x30
[ 1360.548750]  __kasan_kmalloc+0x8f/0xa0
[ 1360.548760]  __kmalloc_node+0x1f1/0x450
[ 1360.548771]  nf_tables_newset+0x10c7/0x1b50 [nf_tables]
[ 1360.548883]  nfnetlink_rcv_batch+0xbc4/0xdc0 [nfnetlink]
[ 1360.548909]  nfnetlink_rcv+0x1a8/0x1e0 [nfnetlink]
[ 1360.548927]  netlink_unicast+0x367/0x4f0
[ 1360.548935]  netlink_sendmsg+0x34b/0x610
[ 1360.548944]  ____sys_sendmsg+0x4d4/0x510
[ 1360.548953]  ___sys_sendmsg+0xc9/0x120
[ 1360.548961]  __sys_sendmsg+0xbe/0x140
[ 1360.548971]  do_syscall_64+0x55/0x120
[ 1360.548982]  entry_SYSCALL_64_after_hwframe+0x55/0x5d
[ 1360.548994] Freed by task 192222:
[ 1360.548999]  kasan_save_stack+0x20/0x40
[ 1360.549009]  kasan_save_track+0x14/0x30
[ 1360.549019]  kasan_save_free_info+0x3b/0x60
[ 1360.549028]  poison_slab_object+0x100/0x180
[ 1360.549036]  __kasan_slab_free+0x14/0x30
[ 1360.549042]  kfree+0xb6/0x260
[ 1360.549049]  __nft_release_table+0x473/0x6a0 [nf_tables]
[ 1360.549131]  nf_tables_exit_net+0x170/0x240 [nf_tables]
[ 1360.549221]  ops_exit_list+0x50/0xa0
[ 1360.549229]  free_exit_list+0x101/0x140
[ 1360.549236]  unregister_pernet_operations+0x107/0x160
[ 1360.549245]  unregister_pernet_subsys+0x1c/0x30
[ 1360.549254]  nf_tables_module_exit+0x43/0x80 [nf_tables]
[ 1360.549345]  __do_sys_delete_module+0x253/0x370
[ 1360.549352]  do_syscall_64+0x55/0x120
[ 1360.549360]  entry_SYSCALL_64_after_hwframe+0x55/0x5d
(gdb) list *__nft_release_table+0x473
0x1e033 is in __nft_release_table (net/netfilter/nf_tables_api.c:11354).
11349           list_for_each_entry_safe(flowtable, nf, &amp;table-&gt;flowtables, list) {
11350                   list_del(&amp;flowtable-&gt;list);
11351                   nft_use_dec(&amp;table-&gt;use);
11352                   nf_tables_flowtable_destroy(flowtable);
11353           }
11354           list_for_each_entry_safe(set, ns, &amp;table-&gt;sets, list) {
11355                   list_del(&amp;set-&gt;list);
11356                   nft_use_dec(&amp;table-&gt;use);
11357                   if (set-&gt;flags &amp; (NFT_SET_MAP | NFT_SET_OBJECT))
11358                           nft_map_deactivat
---truncated---
CVE-2024-38583:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix use-after-free of timer for log writer thread
Patch series &quot;nilfs2: fix log writer related issues&quot;.
This bug fix series covers three nilfs2 log writer-related issues,
including a timer use-after-free issue and potential deadlock issue on
unmount, and a potential freeze issue in event synchronization found
during their analysis.  Details are described in each commit log.
This patch (of 3):
A use-after-free issue has been reported regarding the timer sc_timer on
the nilfs_sc_info structure.
The problem is that even though it is used to wake up a sleeping log
writer thread, sc_timer is not shut down until the nilfs_sc_info structure
is about to be freed, and is used regardless of the thread's lifetime.
Fix this issue by limiting the use of sc_timer only while the log writer
thread is alive.
CVE-2024-35988:In the Linux kernel, the following vulnerability has been resolved:
riscv: Fix TASK_SIZE on 64-bit NOMMU
On NOMMU, userspace memory can come from anywhere in physical RAM. The
current definition of TASK_SIZE is wrong if any RAM exists above 4G,
causing spurious failures in the userspace access routines.
CVE-2024-39489:In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix memleak in seg6_hmac_init_algo
seg6_hmac_init_algo returns without cleaning up the previous allocations
if one fails, so it's going to leak all that memory and the crypto tfms.
Update seg6_hmac_exit to only free the memory when allocated, so we can
reuse the code directly.
CVE-2024-39487:In the Linux kernel, the following vulnerability has been resolved:
bonding: Fix out-of-bounds read in bond_option_arp_ip_targets_set()
In function bond_option_arp_ip_targets_set(), if newval-&gt;string is an
empty string, newval-&gt;string+1 will point to the byte after the
string, causing an out-of-bound read.
BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418
Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107
CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd9/0x150 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:364 [inline]
 print_report+0xc1/0x5e0 mm/kasan/report.c:475
 kasan_report+0xbe/0xf0 mm/kasan/report.c:588
 strlen+0x7d/0xa0 lib/string.c:418
 __fortify_strlen include/linux/fortify-string.h:210 [inline]
 in4_pton+0xa3/0x3f0 net/core/utils.c:130
 bond_option_arp_ip_targets_set+0xc2/0x910
drivers/net/bonding/bond_options.c:1201
 __bond_opt_set+0x2a4/0x1030 drivers/net/bonding/bond_options.c:767
 __bond_opt_set_notify+0x48/0x150 drivers/net/bonding/bond_options.c:792
 bond_opt_tryset_rtnl+0xda/0x160 drivers/net/bonding/bond_options.c:817
 bonding_sysfs_store_option+0xa1/0x120 drivers/net/bonding/bond_sysfs.c:156
 dev_attr_store+0x54/0x80 drivers/base/core.c:2366
 sysfs_kf_write+0x114/0x170 fs/sysfs/file.c:136
 kernfs_fop_write_iter+0x337/0x500 fs/kernfs/file.c:334
 call_write_iter include/linux/fs.h:2020 [inline]
 new_sync_write fs/read_write.c:491 [inline]
 vfs_write+0x96a/0xd80 fs/read_write.c:584
 ksys_write+0x122/0x250 fs/read_write.c:637
 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
---[ end trace ]---
Fix it by adding a check of string length before using it.
CVE-2024-40905:In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible race in __fib6_drop_pcpu_from()
syzbot found a race in __fib6_drop_pcpu_from() [1]
If compiler reads more than once (*ppcpu_rt),
second read could read NULL, if another cpu clears
the value in rt6_get_pcpu_route().
Add a READ_ONCE() to prevent this race.
Also add rcu_read_lock()/rcu_read_unlock() because
we rely on RCU protection while dereferencing pcpu_rt.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]
CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: netns cleanup_net
 RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984
Code: f8 48 c1 e8 03 80 3c 28 00 0f 85 16 02 00 00 4d 8b 3f 4d 85 ff 74 31 e8 74 a7 fa f7 49 8d bf 90 00 00 00 48 89 f8 48 c1 e8 03 &lt;80&gt; 3c 28 00 0f 85 1e 02 00 00 49 8b 87 90 00 00 00 48 8b 0c 24 48
RSP: 0018:ffffc900040df070 EFLAGS: 00010206
RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16
RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091
RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007
R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8
R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001
FS:  0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  __fib6_drop_pcpu_from net/ipv6/ip6_fib.c:966 [inline]
  fib6_drop_pcpu_from net/ipv6/ip6_fib.c:1027 [inline]
  fib6_purge_rt+0x7f2/0x9f0 net/ipv6/ip6_fib.c:1038
  fib6_del_route net/ipv6/ip6_fib.c:1998 [inline]
  fib6_del+0xa70/0x17b0 net/ipv6/ip6_fib.c:2043
  fib6_clean_node+0x426/0x5b0 net/ipv6/ip6_fib.c:2205
  fib6_walk_continue+0x44f/0x8d0 net/ipv6/ip6_fib.c:2127
  fib6_walk+0x182/0x370 net/ipv6/ip6_fib.c:2175
  fib6_clean_tree+0xd7/0x120 net/ipv6/ip6_fib.c:2255
  __fib6_clean_all+0x100/0x2d0 net/ipv6/ip6_fib.c:2271
  rt6_sync_down_dev net/ipv6/route.c:4906 [inline]
  rt6_disable_ip+0x7ed/0xa00 net/ipv6/route.c:4911
  addrconf_ifdown.isra.0+0x117/0x1b40 net/ipv6/addrconf.c:3855
  addrconf_notify+0x223/0x19e0 net/ipv6/addrconf.c:3778
  notifier_call_chain+0xb9/0x410 kernel/notifier.c:93
  call_netdevice_notifiers_info+0xbe/0x140 net/core/dev.c:1992
  call_netdevice_notifiers_extack net/core/dev.c:2030 [inline]
  call_netdevice_notifiers net/core/dev.c:2044 [inline]
  dev_close_many+0x333/0x6a0 net/core/dev.c:1585
  unregister_netdevice_many_notify+0x46d/0x19f0 net/core/dev.c:11193
  unregister_netdevice_many net/core/dev.c:11276 [inline]
  default_device_exit_batch+0x85b/0xae0 net/core/dev.c:11759
  ops_exit_list+0x128/0x180 net/core/net_namespace.c:178
  cleanup_net+0x5b7/0xbf0 net/core/net_namespace.c:640
  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
  process_scheduled_works kernel/workqueue.c:3312 [inline]
  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
  kthread+0x2c1/0x3a0 kernel/kthread.c:389
  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
CVE-2024-40931:In the Linux kernel, the following vulnerability has been resolved:
mptcp: ensure snd_una is properly initialized on connect
This is strictly related to commit fb7a0d334894 (&quot;mptcp: ensure snd_nxt
is properly initialized on connect&quot;). It turns out that syzkaller can
trigger the retransmit after fallback and before processing any other
incoming packet - so that snd_una is still left uninitialized.
Address the issue explicitly initializing snd_una together with snd_nxt
and write_seq.
CVE-2024-39500:In the Linux kernel, the following vulnerability has been resolved:
sock_map: avoid race between sock_map_close and sk_psock_put
sk_psock_get will return NULL if the refcount of psock has gone to 0, which
will happen when the last call of sk_psock_put is done. However,
sk_psock_drop may not have finished yet, so the close callback will still
point to sock_map_close despite psock being NULL.
This can be reproduced with a thread deleting an element from the sock map,
while the second one creates a socket, adds it to the map and closes it.
That will trigger the WARN_ON_ONCE:
------------[ cut here ]------------
WARNING: CPU: 1 PID: 7220 at net/core/sock_map.c:1701 sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
Modules linked in:
CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701
Code: df e8 92 29 88 f8 48 8b 1b 48 89 d8 48 c1 e8 03 42 80 3c 20 00 74 08 48 89 df e8 79 29 88 f8 4c 8b 23 eb 89 e8 4f 15 23 f8 90 &lt;0f&gt; 0b 90 48 83 c4 08 5b 41 5c 41 5d 41 5e 41 5f 5d e9 13 26 3d 02
RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293
RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000
RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0
RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3
R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840
R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870
FS:  000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0
Call Trace:
 &lt;TASK&gt;
 unix_release+0x87/0xc0 net/unix/af_unix.c:1048
 __sock_release net/socket.c:659 [inline]
 sock_close+0xbe/0x240 net/socket.c:1421
 __fput+0x42b/0x8a0 fs/file_table.c:422
 __do_sys_close fs/open.c:1556 [inline]
 __se_sys_close fs/open.c:1541 [inline]
 __x64_sys_close+0x7f/0x110 fs/open.c:1541
 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:0x7fb37d618070
Code: 00 00 48 c7 c2 b8 ff ff ff f7 d8 64 89 02 b8 ff ff ff ff eb d4 e8 10 2c 00 00 80 3d 31 f0 07 00 00 74 17 b8 03 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 48 c3 0f 1f 80 00 00 00 00 48 83 ec 18 89 7c
RSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003
RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070
RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000
R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
 &lt;/TASK&gt;
Use sk_psock, which will only check that the pointer is not been set to
NULL yet, which should only happen after the callbacks are restored. If,
then, a reference can still be gotten, we may call sk_psock_stop and cancel
psock-&gt;work.
As suggested by Paolo Abeni, reorder the condition so the control flow is
less convoluted.
After that change, the reproducer does not trigger the WARN_ON_ONCE
anymore.
CVE-2024-39488:In the Linux kernel, the following vulnerability has been resolved:
arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRY
When CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytes
to bug_table entries, and as a result the last entry in a bug table will
be ignored, potentially leading to an unexpected panic(). All prior
entries in the table will be handled correctly.
The arm64 ABI requires that struct fields of up to 8 bytes are
naturally-aligned, with padding added within a struct such that struct
are suitably aligned within arrays.
When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:
	struct bug_entry {
		signed int      bug_addr_disp;	// 4 bytes
		signed int      file_disp;	// 4 bytes
		unsigned short  line;		// 2 bytes
		unsigned short  flags;		// 2 bytes
	}
... with 12 bytes total, requiring 4-byte alignment.
When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:
	struct bug_entry {
		signed int      bug_addr_disp;	// 4 bytes
		unsigned short  flags;		// 2 bytes
		&lt; implicit padding &gt;		// 2 bytes
	}
... with 8 bytes total, with 6 bytes of data and 2 bytes of trailing
padding, requiring 4-byte alginment.
When we create a bug_entry in assembly, we align the start of the entry
to 4 bytes, which implicitly handles padding for any prior entries.
However, we do not align the end of the entry, and so when
CONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing padding
bytes.
For the main kernel image this is not a problem as find_bug() doesn't
depend on the trailing padding bytes when searching for entries:
	for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)
		if (bugaddr == bug_addr(bug))
			return bug;
However for modules, module_bug_finalize() depends on the trailing
bytes when calculating the number of entries:
	mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);
... and as the last bug_entry lacks the necessary padding bytes, this entry
will not be counted, e.g. in the case of a single entry:
	sechdrs[i].sh_size == 6
	sizeof(struct bug_entry) == 8;
	sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;
Consequently module_find_bug() will miss the last bug_entry when it does:
	for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)
		if (bugaddr == bug_addr(bug))
			goto out;
... which can lead to a kenrel panic due to an unhandled bug.
This can be demonstrated with the following module:
	static int __init buginit(void)
	{
		WARN(1, &quot;hello\n&quot;);
		return 0;
	}
	static void __exit bugexit(void)
	{
	}
	module_init(buginit);
	module_exit(bugexit);
	MODULE_LICENSE(&quot;GPL&quot;);
... which will trigger a kernel panic when loaded:
	------------[ cut here ]------------
	hello
	Unexpected kernel BRK exception at EL1
	Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP
	Modules linked in: hello(O+)
	CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8
	Hardware name: linux,dummy-virt (DT)
	pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
	pc : buginit+0x18/0x1000 [hello]
	lr : buginit+0x18/0x1000 [hello]
	sp : ffff800080533ae0
	x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000
	x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58
	x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0
	x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006
	x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720
	x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312
	x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8
	x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000
	x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000
	x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0
	Call trace:
	 buginit+0x18/0x1000 [hello]
	 do_one_initcall+0x80/0x1c8
	 do_init_module+0x60/0x218
	 load_module+0x1ba4/0x1d70
	 __do_sys_init_module+0x198/0x1d0
	 __arm64_sys_init_module+0x1c/0x28
	 invoke_syscall+0x48/0x114
	 el0_svc
---truncated---
CVE-2024-40974:In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Enforce hcall result buffer validity and size
plpar_hcall(), plpar_hcall9(), and related functions expect callers to
provide valid result buffers of certain minimum size. Currently this
is communicated only through comments in the code and the compiler has
no idea.
For example, if I write a bug like this:
  long retbuf[PLPAR_HCALL_BUFSIZE]; // should be PLPAR_HCALL9_BUFSIZE
  plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf, ...);
This compiles with no diagnostics emitted, but likely results in stack
corruption at runtime when plpar_hcall9() stores results past the end
of the array. (To be clear this is a contrived example and I have not
found a real instance yet.)
To make this class of error less likely, we can use explicitly-sized
array parameters instead of pointers in the declarations for the hcall
APIs. When compiled with -Warray-bounds[1], the code above now
provokes a diagnostic like this:
error: array argument is too small;
is of size 32, callee requires at least 72 [-Werror,-Warray-bounds]
   60 |                 plpar_hcall9(H_ALLOCATE_VAS_WINDOW, retbuf,
      |                 ^                                   ~~~~~~
[1] Enabled for LLVM builds but not GCC for now. See commit
    0da6e5fd6c37 (&quot;gcc: disable '-Warray-bounds' for gcc-13 too&quot;) and
    related changes.
CVE-2021-47200:In the Linux kernel, the following vulnerability has been resolved:
drm/prime: Fix use after free in mmap with drm_gem_ttm_mmap
drm_gem_ttm_mmap() drops a reference to the gem object on success. If
the gem object's refcount == 1 on entry to drm_gem_prime_mmap(), that
drop will free the gem object, and the subsequent drm_gem_object_get()
will be a UAF. Fix by grabbing a reference before calling the mmap
helper.
This issue was forseen when the reference dropping was adding in
commit 9786b65bc61ac (&quot;drm/ttm: fix mmap refcounting&quot;):
  &quot;For that to work properly the drm_gem_object_get() call in
  drm_gem_ttm_mmap() must be moved so it happens before calling
  obj-&gt;funcs-&gt;mmap(), otherwise the gem refcount would go down
  to zero.&quot;
CVE-2024-40943:In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix races between hole punching and AIO+DIO
After commit &quot;ocfs2: return real error code in ocfs2_dio_wr_get_block&quot;,
fstests/generic/300 become from always failed to sometimes failed:
========================================================================
[  473.293420 ] run fstests generic/300
[  475.296983 ] JBD2: Ignoring recovery information on journal
[  475.302473 ] ocfs2: Mounting device (253,1) on (node local, slot 0) with ordered data mode.
[  494.290998 ] OCFS2: ERROR (device dm-1): ocfs2_change_extent_flag: Owner 5668 has an extent at cpos 78723 which can no longer be found
[  494.291609 ] On-disk corruption discovered. Please run fsck.ocfs2 once the filesystem is unmounted.
[  494.292018 ] OCFS2: File system is now read-only.
[  494.292224 ] (kworker/19:11,2628,19):ocfs2_mark_extent_written:5272 ERROR: status = -30
[  494.292602 ] (kworker/19:11,2628,19):ocfs2_dio_end_io_write:2374 ERROR: status = -3
fio: io_u error on file /mnt/scratch/racer: Read-only file system: write offset=460849152, buflen=131072
=========================================================================
In __blockdev_direct_IO, ocfs2_dio_wr_get_block is called to add unwritten
extents to a list.  extents are also inserted into extent tree in
ocfs2_write_begin_nolock.  Then another thread call fallocate to puch a
hole at one of the unwritten extent.  The extent at cpos was removed by
ocfs2_remove_extent().  At end io worker thread, ocfs2_search_extent_list
found there is no such extent at the cpos.
    T1                        T2                T3
                              inode lock
                                ...
                                insert extents
                                ...
                              inode unlock
ocfs2_fallocate
 __ocfs2_change_file_space
  inode lock
  lock ip_alloc_sem
  ocfs2_remove_inode_range inode
   ocfs2_remove_btree_range
    ocfs2_remove_extent
    ^---remove the extent at cpos 78723
  ...
  unlock ip_alloc_sem
  inode unlock
                                       ocfs2_dio_end_io
                                        ocfs2_dio_end_io_write
                                         lock ip_alloc_sem
                                         ocfs2_mark_extent_written
                                          ocfs2_change_extent_flag
                                           ocfs2_search_extent_list
                                           ^---failed to find extent
                                          ...
                                          unlock ip_alloc_sem
In most filesystems, fallocate is not compatible with racing with AIO+DIO,
so fix it by adding to wait for all dio before fallocate/punch_hole like
ext4.
CVE-2023-52674:In the Linux kernel, the following vulnerability has been resolved:
ALSA: scarlett2: Add clamp() in scarlett2_mixer_ctl_put()
Ensure the value passed to scarlett2_mixer_ctl_put() is between 0 and
SCARLETT2_MIXER_MAX_VALUE so we don't attempt to access outside
scarlett2_mixer_values[].
CVE-2024-35904:In the Linux kernel, the following vulnerability has been resolved:
selinux: avoid dereference of garbage after mount failure
In case kern_mount() fails and returns an error pointer return in the
error branch instead of continuing and dereferencing the error pointer.
While on it drop the never read static variable selinuxfs_mount.
CVE-2024-40984:In the Linux kernel, the following vulnerability has been resolved:
ACPICA: Revert &quot;ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine.&quot;
Undo the modifications made in commit d410ee5109a1 (&quot;ACPICA: avoid
&quot;Info: mapping multiple BARs. Your kernel is fine.&quot;&quot;). The initial
purpose of this commit was to stop memory mappings for operation
regions from overlapping page boundaries, as it can trigger warnings
if different page attributes are present.
However, it was found that when this situation arises, mapping
continues until the boundary's end, but there is still an attempt to
read/write the entire length of the map, leading to a NULL pointer
deference. For example, if a four-byte mapping request is made but
only one byte is mapped because it hits the current page boundary's
end, a four-byte read/write attempt is still made, resulting in a NULL
pointer deference.
Instead, map the entire length, as the ACPI specification does not
mandate that it must be within the same page boundary. It is
permissible for it to be mapped across different regions.
CVE-2024-40971:In the Linux kernel, the following vulnerability has been resolved:
f2fs: remove clear SB_INLINECRYPT flag in default_options
In f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.
If create new file or open file during this gap, these files
will not use inlinecrypt. Worse case, it may lead to data
corruption if wrappedkey_v0 is enable.
Thread A:                               Thread B:
-f2fs_remount				-f2fs_file_open or f2fs_new_inode
  -default_options
	&lt;- clear SB_INLINECRYPT flag
                                          -fscrypt_select_encryption_impl
  -parse_options
	&lt;- set SB_INLINECRYPT again
CVE-2024-39505:In the Linux kernel, the following vulnerability has been resolved:
drm/komeda: check for error-valued pointer
komeda_pipeline_get_state() may return an error-valued pointer, thus
check the pointer for negative or null value before dereferencing.
CVE-2024-40953:In the Linux kernel, the following vulnerability has been resolved:
KVM: Fix a data race on last_boosted_vcpu in kvm_vcpu_on_spin()
Use {READ,WRITE}_ONCE() to access kvm-&gt;last_boosted_vcpu to ensure the
loads and stores are atomic.  In the extremely unlikely scenario the
compiler tears the stores, it's theoretically possible for KVM to attempt
to get a vCPU using an out-of-bounds index, e.g. if the write is split
into multiple 8-bit stores, and is paired with a 32-bit load on a VM with
257 vCPUs:
  CPU0                              CPU1
  last_boosted_vcpu = 0xff;
                                    (last_boosted_vcpu = 0x100)
                                    last_boosted_vcpu[15:8] = 0x01;
  i = (last_boosted_vcpu = 0x1ff)
                                    last_boosted_vcpu[7:0] = 0x00;
  vcpu = kvm-&gt;vcpu_array[0x1ff];
As detected by KCSAN:
  BUG: KCSAN: data-race in kvm_vcpu_on_spin [kvm] / kvm_vcpu_on_spin [kvm]
  write to 0xffffc90025a92344 of 4 bytes by task 4340 on cpu 16:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4112) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
		 arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c:890)
  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 0xffffc90025a92344 of 4 bytes by task 4342 on cpu 4:
  kvm_vcpu_on_spin (arch/x86/kvm/../../../virt/kvm/kvm_main.c:4069) kvm
  handle_pause (arch/x86/kvm/vmx/vmx.c:5929) kvm_intel
  vmx_handle_exit (arch/x86/kvm/vmx/vmx.c:?
			arch/x86/kvm/vmx/vmx.c:6606) kvm_intel
  vcpu_run (arch/x86/kvm/x86.c:11107 arch/x86/kvm/x86.c:11211) kvm
  kvm_arch_vcpu_ioctl_run (arch/x86/kvm/x86.c:?) kvm
  kvm_vcpu_ioctl (arch/x86/kvm/../../../virt/kvm/kvm_main.c:?) kvm
  __se_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:904 fs/ioctl.c:890)
  __x64_sys_ioctl (fs/ioctl.c:890)
  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: 0x00000012 -&gt; 0x00000000
CVE-2023-52781:In the Linux kernel, the following vulnerability has been resolved:
usb: config: fix iteration issue in 'usb_get_bos_descriptor()'
The BOS descriptor defines a root descriptor and is the base descriptor for
accessing a family of related descriptors.
Function 'usb_get_bos_descriptor()' encounters an iteration issue when
skipping the 'USB_DT_DEVICE_CAPABILITY' descriptor type. This results in
the same descriptor being read repeatedly.
To address this issue, a 'goto' statement is introduced to ensure that the
pointer and the amount read is updated correctly. This ensures that the
function iterates to the next descriptor instead of reading the same
descriptor repeatedly.
CVE-2024-40972:In the Linux kernel, the following vulnerability has been resolved:
ext4: do not create EA inode under buffer lock
ext4_xattr_set_entry() creates new EA inodes while holding buffer lock
on the external xattr block. This is problematic as it nests all the
allocation locking (which acquires locks on other buffers) under the
buffer lock. This can even deadlock when the filesystem is corrupted and
e.g. quota file is setup to contain xattr block as data block. Move the
allocation of EA inode out of ext4_xattr_set_entry() into the callers.
CVE-2024-41005:In the Linux kernel, the following vulnerability has been resolved:
netpoll: Fix race condition in netpoll_owner_active
KCSAN detected a race condition in netpoll:
	BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb
	write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:
	net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)
&lt;snip&gt;
	read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:
	netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)
	netpoll_send_udp (net/core/netpoll.c:?)
&lt;snip&gt;
	value changed: 0x0000000a -&gt; 0xffffffff
This happens because netpoll_owner_active() needs to check if the
current CPU is the owner of the lock, touching napi-&gt;poll_owner
non atomically. The -&gt;poll_owner field contains the current CPU holding
the lock.
Use an atomic read to check if the poll owner is the current CPU.
CVE-2024-39508:In the Linux kernel, the following vulnerability has been resolved:
io_uring/io-wq: Use set_bit() and test_bit() at worker-&gt;flags
Utilize set_bit() and test_bit() on worker-&gt;flags within io_uring/io-wq
to address potential data races.
The structure io_worker-&gt;flags may be accessed through various data
paths, leading to concurrency issues. When KCSAN is enabled, it reveals
data races occurring in io_worker_handle_work and
io_wq_activate_free_worker functions.
	 BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker
	 write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:
	 io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)
	 io_wq_worker (io_uring/io-wq.c:?)
&lt;snip&gt;
	 read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:
	 io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)
	 io_wq_enqueue (io_uring/io-wq.c:947)
	 io_queue_iowq (io_uring/io_uring.c:524)
	 io_req_task_submit (io_uring/io_uring.c:1511)
	 io_handle_tw_list (io_uring/io_uring.c:1198)
&lt;snip&gt;
Line numbers against commit 18daea77cca6 (&quot;Merge tag 'for-linus' of
git://git.kernel.org/pub/scm/virt/kvm/kvm&quot;).
These races involve writes and reads to the same memory location by
different tasks running on different CPUs. To mitigate this, refactor
the code to use atomic operations such as set_bit(), test_bit(), and
clear_bit() instead of basic &quot;and&quot; and &quot;or&quot; operations. This ensures
thread-safe manipulation of worker flags.
Also, move `create_index` to avoid holes in the structure.
CVE-2023-52833:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: btusb: Add date-&gt;evt_skb is NULL check
fix crash because of null pointers
[ 6104.969662] BUG: kernel NULL pointer dereference, address: 00000000000000c8
[ 6104.969667] #PF: supervisor read access in kernel mode
[ 6104.969668] #PF: error_code(0x0000) - not-present page
[ 6104.969670] PGD 0 P4D 0
[ 6104.969673] Oops: 0000 [#1] SMP NOPTI
[ 6104.969684] RIP: 0010:btusb_mtk_hci_wmt_sync+0x144/0x220 [btusb]
[ 6104.969688] RSP: 0018:ffffb8d681533d48 EFLAGS: 00010246
[ 6104.969689] RAX: 0000000000000000 RBX: ffff8ad560bb2000 RCX: 0000000000000006
[ 6104.969691] RDX: 0000000000000000 RSI: ffffb8d681533d08 RDI: 0000000000000000
[ 6104.969692] RBP: ffffb8d681533d70 R08: 0000000000000001 R09: 0000000000000001
[ 6104.969694] R10: 0000000000000001 R11: 00000000fa83b2da R12: ffff8ad461d1d7c0
[ 6104.969695] R13: 0000000000000000 R14: ffff8ad459618c18 R15: ffffb8d681533d90
[ 6104.969697] FS:  00007f5a1cab9d40(0000) GS:ffff8ad578200000(0000) knlGS:00000
[ 6104.969699] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 6104.969700] CR2: 00000000000000c8 CR3: 000000018620c001 CR4: 0000000000760ef0
[ 6104.969701] PKRU: 55555554
[ 6104.969702] Call Trace:
[ 6104.969708]  btusb_mtk_shutdown+0x44/0x80 [btusb]
[ 6104.969732]  hci_dev_do_close+0x470/0x5c0 [bluetooth]
[ 6104.969748]  hci_rfkill_set_block+0x56/0xa0 [bluetooth]
[ 6104.969753]  rfkill_set_block+0x92/0x160
[ 6104.969755]  rfkill_fop_write+0x136/0x1e0
[ 6104.969759]  __vfs_write+0x18/0x40
[ 6104.969761]  vfs_write+0xdf/0x1c0
[ 6104.969763]  ksys_write+0xb1/0xe0
[ 6104.969765]  __x64_sys_write+0x1a/0x20
[ 6104.969769]  do_syscall_64+0x51/0x180
[ 6104.969771]  entry_SYSCALL_64_after_hwframe+0x44/0xa9
[ 6104.969773] RIP: 0033:0x7f5a21f18fef
[ 6104.9] RSP: 002b:00007ffeefe39010 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
[ 6104.969780] RAX: ffffffffffffffda RBX: 000055c10a7560a0 RCX: 00007f5a21f18fef
[ 6104.969781] RDX: 0000000000000008 RSI: 00007ffeefe39060 RDI: 0000000000000012
[ 6104.969782] RBP: 00007ffeefe39060 R08: 0000000000000000 R09: 0000000000000017
[ 6104.969784] R10: 00007ffeefe38d97 R11: 0000000000000293 R12: 0000000000000002
[ 6104.969785] R13: 00007ffeefe39220 R14: 00007ffeefe391a0 R15: 000055c10a72acf0
CVE-2024-40932:In the Linux kernel, the following vulnerability has been resolved:
drm/exynos/vidi: fix memory leak in .get_modes()
The duplicated EDID is never freed. Fix it.
CVE-2024-39506:In the Linux kernel, the following vulnerability has been resolved:
liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packet
In lio_vf_rep_copy_packet() pg_info-&gt;page is compared to a NULL value,
but then it is unconditionally passed to skb_add_rx_frag() which looks
strange and could lead to null pointer dereference.
lio_vf_rep_copy_packet() call trace looks like:
	octeon_droq_process_packets
	 octeon_droq_fast_process_packets
	  octeon_droq_dispatch_pkt
	   octeon_create_recv_info
	    ...search in the dispatch_list...
	     -&gt;disp_fn(rdisp-&gt;rinfo, ...)
	      lio_vf_rep_pkt_recv(struct octeon_recv_info *recv_info, ...)
In this path there is no code which sets pg_info-&gt;page to NULL.
So this check looks unneeded and doesn't solve potential problem.
But I guess the author had reason to add a check and I have no such card
and can't do real test.
In addition, the code in the function liquidio_push_packet() in
liquidio/lio_core.c does exactly the same.
Based on this, I consider the most acceptable compromise solution to
adjust this issue by moving skb_add_rx_frag() into conditional scope.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-40960:In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible NULL dereference in rt6_probe()
syzbot caught a NULL dereference in rt6_probe() [1]
Bail out if  __in6_dev_get() returns NULL.
[1]
Oops: general protection fault, probably for non-canonical address 0xdffffc00000000cb: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]
CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
 RIP: 0010:rt6_probe net/ipv6/route.c:656 [inline]
 RIP: 0010:find_match+0x8c4/0xf50 net/ipv6/route.c:758
Code: 14 fd f7 48 8b 85 38 ff ff ff 48 c7 45 b0 00 00 00 00 48 8d b8 5c 06 00 00 48 b8 00 00 00 00 00 fc ff df 48 89 fa 48 c1 ea 03 &lt;0f&gt; b6 14 02 48 89 f8 83 e0 07 83 c0 03 38 d0 7c 08 84 d2 0f 85 19
RSP: 0018:ffffc900034af070 EFLAGS: 00010203
RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000
RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065c
RBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000
R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000a
R13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000
FS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  rt6_nh_find_match+0xfa/0x1a0 net/ipv6/route.c:784
  nexthop_for_each_fib6_nh+0x26d/0x4a0 net/ipv4/nexthop.c:1496
  __find_rr_leaf+0x6e7/0xe00 net/ipv6/route.c:825
  find_rr_leaf net/ipv6/route.c:853 [inline]
  rt6_select net/ipv6/route.c:897 [inline]
  fib6_table_lookup+0x57e/0xa30 net/ipv6/route.c:2195
  ip6_pol_route+0x1cd/0x1150 net/ipv6/route.c:2231
  pol_lookup_func include/net/ip6_fib.h:616 [inline]
  fib6_rule_lookup+0x386/0x720 net/ipv6/fib6_rules.c:121
  ip6_route_output_flags_noref net/ipv6/route.c:2639 [inline]
  ip6_route_output_flags+0x1d0/0x640 net/ipv6/route.c:2651
  ip6_dst_lookup_tail.constprop.0+0x961/0x1760 net/ipv6/ip6_output.c:1147
  ip6_dst_lookup_flow+0x99/0x1d0 net/ipv6/ip6_output.c:1250
  rawv6_sendmsg+0xdab/0x4340 net/ipv6/raw.c:898
  inet_sendmsg+0x119/0x140 net/ipv4/af_inet.c:853
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg net/socket.c:745 [inline]
  sock_write_iter+0x4b8/0x5c0 net/socket.c:1160
  new_sync_write fs/read_write.c:497 [inline]
  vfs_write+0x6b6/0x1140 fs/read_write.c:590
  ksys_write+0x1f8/0x260 fs/read_write.c:643
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x250 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CVE-2024-36939:In the Linux kernel, the following vulnerability has been resolved:
nfs: Handle error of rpc_proc_register() in nfs_net_init().
syzkaller reported a warning [0] triggered while destroying immature
netns.
rpc_proc_register() was called in init_nfs_fs(), but its error
has been ignored since at least the initial commit 1da177e4c3f4
(&quot;Linux-2.6.12-rc2&quot;).
Recently, commit d47151b79e32 (&quot;nfs: expose /proc/net/sunrpc/nfs
in net namespaces&quot;) converted the procfs to per-netns and made
the problem more visible.
Even when rpc_proc_register() fails, nfs_net_init() could succeed,
and thus nfs_net_exit() will be called while destroying the netns.
Then, remove_proc_entry() will be called for non-existing proc
directory and trigger the warning below.
Let's handle the error of rpc_proc_register() properly in nfs_net_init().
[0]:
name 'nfs'
WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
Modules linked in:
CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711
Code: 41 5d 41 5e c3 e8 85 09 b5 ff 48 c7 c7 88 58 64 86 e8 09 0e 71 02 e8 74 09 b5 ff 4c 89 e6 48 c7 c7 de 1b 80 84 e8 c5 ad 97 ff &lt;0f&gt; 0b eb b1 e8 5c 09 b5 ff 48 c7 c7 88 58 64 86 e8 e0 0d 71 02 eb
RSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286
RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503c
RDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001
RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffc
R13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8
FS:  00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 rpc_proc_unregister+0x64/0x70 net/sunrpc/stats.c:310
 nfs_net_exit+0x1c/0x30 fs/nfs/inode.c:2438
 ops_exit_list+0x62/0xb0 net/core/net_namespace.c:170
 setup_net+0x46c/0x660 net/core/net_namespace.c:372
 copy_net_ns+0x244/0x590 net/core/net_namespace.c:505
 create_new_namespaces+0x2ed/0x770 kernel/nsproxy.c:110
 unshare_nsproxy_namespaces+0xae/0x160 kernel/nsproxy.c:228
 ksys_unshare+0x342/0x760 kernel/fork.c:3322
 __do_sys_unshare kernel/fork.c:3393 [inline]
 __se_sys_unshare kernel/fork.c:3391 [inline]
 __x64_sys_unshare+0x1f/0x30 kernel/fork.c:3391
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x4f/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x46/0x4e
RIP: 0033:0x7f30d0febe5d
Code: ff c3 66 2e 0f 1f 84 00 00 00 00 00 90 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 73 9f 1b 00 f7 d8 64 89 01 48
RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110
RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5d
RDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600
RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002
R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000
 &lt;/TASK&gt;
CVE-2022-48666:In the Linux kernel, the following vulnerability has been resolved:
scsi: core: Fix a use-after-free
There are two .exit_cmd_priv implementations. Both implementations use
resources associated with the SCSI host. Make sure that these resources are
still available when .exit_cmd_priv is called by waiting inside
scsi_remove_host() until the tag set has been freed.
This commit fixes the following use-after-free:
==================================================================
BUG: KASAN: use-after-free in srp_exit_cmd_priv+0x27/0xd0 [ib_srp]
Read of size 8 at addr ffff888100337000 by task multipathd/16727
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x34/0x44
 print_report.cold+0x5e/0x5db
 kasan_report+0xab/0x120
 srp_exit_cmd_priv+0x27/0xd0 [ib_srp]
 scsi_mq_exit_request+0x4d/0x70
 blk_mq_free_rqs+0x143/0x410
 __blk_mq_free_map_and_rqs+0x6e/0x100
 blk_mq_free_tag_set+0x2b/0x160
 scsi_host_dev_release+0xf3/0x1a0
 device_release+0x54/0xe0
 kobject_put+0xa5/0x120
 device_release+0x54/0xe0
 kobject_put+0xa5/0x120
 scsi_device_dev_release_usercontext+0x4c1/0x4e0
 execute_in_process_context+0x23/0x90
 device_release+0x54/0xe0
 kobject_put+0xa5/0x120
 scsi_disk_release+0x3f/0x50
 device_release+0x54/0xe0
 kobject_put+0xa5/0x120
 disk_release+0x17f/0x1b0
 device_release+0x54/0xe0
 kobject_put+0xa5/0x120
 dm_put_table_device+0xa3/0x160 [dm_mod]
 dm_put_device+0xd0/0x140 [dm_mod]
 free_priority_group+0xd8/0x110 [dm_multipath]
 free_multipath+0x94/0xe0 [dm_multipath]
 dm_table_destroy+0xa2/0x1e0 [dm_mod]
 __dm_destroy+0x196/0x350 [dm_mod]
 dev_remove+0x10c/0x160 [dm_mod]
 ctl_ioctl+0x2c2/0x590 [dm_mod]
 dm_ctl_ioctl+0x5/0x10 [dm_mod]
 __x64_sys_ioctl+0xb4/0xf0
 dm_ctl_ioctl+0x5/0x10 [dm_mod]
 __x64_sys_ioctl+0xb4/0xf0
 do_syscall_64+0x3b/0x90
 entry_SYSCALL_64_after_hwframe+0x46/0xb0
CVE-2021-47432:In the Linux kernel, the following vulnerability has been resolved:
lib/generic-radix-tree.c: Don't overflow in peek()
When we started spreading new inode numbers throughout most of the 64
bit inode space, that triggered some corner case bugs, in particular
some integer overflows related to the radix tree code. Oops.
CVE-2024-40983:In the Linux kernel, the following vulnerability has been resolved:
tipc: force a dst refcount before doing decryption
As it says in commit 3bc07321ccc2 (&quot;xfrm: Force a dst refcount before
entering the xfrm type handlers&quot;):
&quot;Crypto requests might return asynchronous. In this case we leave the
 rcu protected region, so force a refcount on the skb's destination
 entry before we enter the xfrm type input/output handlers.&quot;
On TIPC decryption path it has the same problem, and skb_dst_force()
should be called before doing decryption to avoid a possible crash.
Shuang reported this issue when this warning is triggered:
  [] WARNING: include/net/dst.h:337 tipc_sk_rcv+0x1055/0x1ea0 [tipc]
  [] Kdump: loaded Tainted: G W --------- - - 4.18.0-496.el8.x86_64+debug
  [] Workqueue: crypto cryptd_queue_worker
  [] RIP: 0010:tipc_sk_rcv+0x1055/0x1ea0 [tipc]
  [] Call Trace:
  [] tipc_sk_mcast_rcv+0x548/0xea0 [tipc]
  [] tipc_rcv+0xcf5/0x1060 [tipc]
  [] tipc_aead_decrypt_done+0x215/0x2e0 [tipc]
  [] cryptd_aead_crypt+0xdb/0x190
  [] cryptd_queue_worker+0xed/0x190
  [] process_one_work+0x93d/0x17e0
CVE-2024-39499:In the Linux kernel, the following vulnerability has been resolved:
vmci: prevent speculation leaks by sanitizing event in event_deliver()
Coverity spotted that event_msg is controlled by user-space,
event_msg-&gt;event_data.event is passed to event_deliver() and used
as an index without sanitization.
This change ensures that the event index is sanitized to mitigate any
possibility of speculative information leaks.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
Only compile tested, no access to HW.
CVE-2024-40945:In the Linux kernel, the following vulnerability has been resolved:
iommu: Return right value in iommu_sva_bind_device()
iommu_sva_bind_device() should return either a sva bond handle or an
ERR_PTR value in error cases. Existing drivers (idxd and uacce) only
check the return value with IS_ERR(). This could potentially lead to
a kernel NULL pointer dereference issue if the function returns NULL
instead of an error pointer.
In reality, this doesn't cause any problems because iommu_sva_bind_device()
only returns NULL when the kernel is not configured with CONFIG_IOMMU_SVA.
In this case, iommu_dev_enable_feature(dev, IOMMU_DEV_FEAT_SVA) will
return an error, and the device drivers won't call iommu_sva_bind_device()
at all.
CVE-2024-37078:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix potential kernel bug due to lack of writeback flag waiting
Destructive writes to a block device on which nilfs2 is mounted can cause
a kernel bug in the folio/page writeback start routine or writeback end
routine (__folio_start_writeback in the log below):
 kernel BUG at mm/page-writeback.c:3070!
 Oops: invalid opcode: 0000 [#1] PREEMPT SMP KASAN PTI
 ...
 RIP: 0010:__folio_start_writeback+0xbaa/0x10e0
 Code: 25 ff 0f 00 00 0f 84 18 01 00 00 e8 40 ca c6 ff e9 17 f6 ff ff
  e8 36 ca c6 ff 4c 89 f7 48 c7 c6 80 c0 12 84 e8 e7 b3 0f 00 90 &lt;0f&gt;
  0b e8 1f ca c6 ff 4c 89 f7 48 c7 c6 a0 c6 12 84 e8 d0 b3 0f 00
 ...
 Call Trace:
  &lt;TASK&gt;
  nilfs_segctor_do_construct+0x4654/0x69d0 [nilfs2]
  nilfs_segctor_construct+0x181/0x6b0 [nilfs2]
  nilfs_segctor_thread+0x548/0x11c0 [nilfs2]
  kthread+0x2f0/0x390
  ret_from_fork+0x4b/0x80
  ret_from_fork_asm+0x1a/0x30
  &lt;/TASK&gt;
This is because when the log writer starts a writeback for segment summary
blocks or a super root block that use the backing device's page cache, it
does not wait for the ongoing folio/page writeback, resulting in an
inconsistent writeback state.
Fix this issue by waiting for ongoing writebacks when putting
folios/pages on the backing device into writeback state.
CVE-2024-40967:In the Linux kernel, the following vulnerability has been resolved:
serial: imx: Introduce timeout when waiting on transmitter empty
By waiting at most 1 second for USR2_TXDC to be set, we avoid a potential
deadlock.
In case of the timeout, there is not much we can do, so we simply ignore
the transmitter state and optimistically try to continue.
CVE-2024-40987:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix UBSAN warning in kv_dpm.c
Adds bounds check for sumo_vid_mapping_entry.
CVE-2024-40995:In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_api: fix possible infinite loop in tcf_idr_check_alloc()
syzbot found hanging tasks waiting on rtnl_lock [1]
A reproducer is available in the syzbot bug.
When a request to add multiple actions with the same index is sent, the
second request will block forever on the first request. This holds
rtnl_lock, and causes tasks to hang.
Return -EAGAIN to prevent infinite looping, while keeping documented
behavior.
[1]
INFO: task kworker/1:0:5088 blocked for more than 143 seconds.
Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0
&quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000
Workqueue: events_power_efficient reg_check_chans_work
Call Trace:
&lt;TASK&gt;
context_switch kernel/sched/core.c:5409 [inline]
__schedule+0xf15/0x5d00 kernel/sched/core.c:6746
__schedule_loop kernel/sched/core.c:6823 [inline]
schedule+0xe7/0x350 kernel/sched/core.c:6838
schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:6895
__mutex_lock_common kernel/locking/mutex.c:684 [inline]
__mutex_lock+0x5b8/0x9c0 kernel/locking/mutex.c:752
wiphy_lock include/net/cfg80211.h:5953 [inline]
reg_leave_invalid_chans net/wireless/reg.c:2466 [inline]
reg_check_chans_work+0x10a/0x10e0 net/wireless/reg.c:2481
CVE-2024-38559:In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Ensure the copied buf is NUL terminated
Currently, we allocate a count-sized kernel buffer and copy count from
userspace to that buffer. Later, we use kstrtouint on this buffer but we
don't ensure that the string is terminated inside the buffer, this can
lead to OOB read when using kstrtouint. Fix this issue by using
memdup_user_nul instead of memdup_user.
CVE-2024-38578:In the Linux kernel, the following vulnerability has been resolved:
ecryptfs: Fix buffer size for tag 66 packet
The 'TAG 66 Packet Format' description is missing the cipher code and
checksum fields that are packed into the message packet. As a result,
the buffer allocated for the packet is 3 bytes too small and
write_tag_66_packet() will write up to 3 bytes past the end of the
buffer.
Fix this by increasing the size of the allocation so the whole packet
will always fit in the buffer.
This fixes the below kasan slab-out-of-bounds bug:
  BUG: KASAN: slab-out-of-bounds in ecryptfs_generate_key_packet_set+0x7d6/0xde0
  Write of size 1 at addr ffff88800afbb2a5 by task touch/181
  CPU: 0 PID: 181 Comm: touch Not tainted 6.6.13-gnu #1 4c9534092be820851bb687b82d1f92a426598dc6
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2/GNU Guix 04/01/2014
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x4c/0x70
   print_report+0xc5/0x610
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   ? kasan_complete_mode_report_info+0x44/0x210
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   kasan_report+0xc2/0x110
   ? ecryptfs_generate_key_packet_set+0x7d6/0xde0
   __asan_store1+0x62/0x80
   ecryptfs_generate_key_packet_set+0x7d6/0xde0
   ? __pfx_ecryptfs_generate_key_packet_set+0x10/0x10
   ? __alloc_pages+0x2e2/0x540
   ? __pfx_ovl_open+0x10/0x10 [overlay 30837f11141636a8e1793533a02e6e2e885dad1d]
   ? dentry_open+0x8f/0xd0
   ecryptfs_write_metadata+0x30a/0x550
   ? __pfx_ecryptfs_write_metadata+0x10/0x10
   ? ecryptfs_get_lower_file+0x6b/0x190
   ecryptfs_initialize_file+0x77/0x150
   ecryptfs_create+0x1c2/0x2f0
   path_openat+0x17cf/0x1ba0
   ? __pfx_path_openat+0x10/0x10
   do_filp_open+0x15e/0x290
   ? __pfx_do_filp_open+0x10/0x10
   ? __kasan_check_write+0x18/0x30
   ? _raw_spin_lock+0x86/0xf0
   ? __pfx__raw_spin_lock+0x10/0x10
   ? __kasan_check_write+0x18/0x30
   ? alloc_fd+0xf4/0x330
   do_sys_openat2+0x122/0x160
   ? __pfx_do_sys_openat2+0x10/0x10
   __x64_sys_openat+0xef/0x170
   ? __pfx___x64_sys_openat+0x10/0x10
   do_syscall_64+0x60/0xd0
   entry_SYSCALL_64_after_hwframe+0x6e/0xd8
  RIP: 0033:0x7f00a703fd67
  Code: 25 00 00 41 00 3d 00 00 41 00 74 37 64 8b 04 25 18 00 00 00 85 c0 75 5b 44 89 e2 48 89 ee bf 9c ff ff ff b8 01 01 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 0f 87 85 00 00 00 48 83 c4 68 5d 41 5c c3 0f 1f
  RSP: 002b:00007ffc088e30b0 EFLAGS: 00000246 ORIG_RAX: 0000000000000101
  RAX: ffffffffffffffda RBX: 00007ffc088e3368 RCX: 00007f00a703fd67
  RDX: 0000000000000941 RSI: 00007ffc088e48d7 RDI: 00000000ffffff9c
  RBP: 00007ffc088e48d7 R08: 0000000000000001 R09: 0000000000000000
  R10: 00000000000001b6 R11: 0000000000000246 R12: 0000000000000941
  R13: 0000000000000000 R14: 00007ffc088e48d7 R15: 00007f00a7180040
   &lt;/TASK&gt;
  Allocated by task 181:
   kasan_save_stack+0x2f/0x60
   kasan_set_track+0x29/0x40
   kasan_save_alloc_info+0x25/0x40
   __kasan_kmalloc+0xc5/0xd0
   __kmalloc+0x66/0x160
   ecryptfs_generate_key_packet_set+0x6d2/0xde0
   ecryptfs_write_metadata+0x30a/0x550
   ecryptfs_initialize_file+0x77/0x150
   ecryptfs_create+0x1c2/0x2f0
   path_openat+0x17cf/0x1ba0
   do_filp_open+0x15e/0x290
   do_sys_openat2+0x122/0x160
   __x64_sys_openat+0xef/0x170
   do_syscall_64+0x60/0xd0
   entry_SYSCALL_64_after_hwframe+0x6e/0xd8
CVE-2024-41004:In the Linux kernel, the following vulnerability has been resolved:
tracing: Build event generation tests only as modules
The kprobes and synth event generation test modules add events and lock
(get a reference) those event file reference in module init function,
and unlock and delete it in module exit function. This is because those
are designed for playing as modules.
If we make those modules as built-in, those events are left locked in the
kernel, and never be removed. This causes kprobe event self-test failure
as below.
[   97.349708] ------------[ cut here ]------------
[   97.353453] WARNING: CPU: 3 PID: 1 at kernel/trace/trace_kprobe.c:2133 kprobe_trace_self_tests_init+0x3f1/0x480
[   97.357106] Modules linked in:
[   97.358488] CPU: 3 PID: 1 Comm: swapper/0 Not tainted 6.9.0-g699646734ab5-dirty #14
[   97.361556] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
[   97.363880] RIP: 0010:kprobe_trace_self_tests_init+0x3f1/0x480
[   97.365538] Code: a8 24 08 82 e9 ae fd ff ff 90 0f 0b 90 48 c7 c7 e5 aa 0b 82 e9 ee fc ff ff 90 0f 0b 90 48 c7 c7 2d 61 06 82 e9 8e fd ff ff 90 &lt;0f&gt; 0b 90 48 c7 c7 33 0b 0c 82 89 c6 e8 6e 03 1f ff 41 ff c7 e9 90
[   97.370429] RSP: 0000:ffffc90000013b50 EFLAGS: 00010286
[   97.371852] RAX: 00000000fffffff0 RBX: ffff888005919c00 RCX: 0000000000000000
[   97.373829] RDX: ffff888003f40000 RSI: ffffffff8236a598 RDI: ffff888003f40a68
[   97.375715] RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000
[   97.377675] R10: ffffffff811c9ae5 R11: ffffffff8120c4e0 R12: 0000000000000000
[   97.379591] R13: 0000000000000001 R14: 0000000000000015 R15: 0000000000000000
[   97.381536] FS:  0000000000000000(0000) GS:ffff88807dcc0000(0000) knlGS:0000000000000000
[   97.383813] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   97.385449] CR2: 0000000000000000 CR3: 0000000002244000 CR4: 00000000000006b0
[   97.387347] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   97.389277] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   97.391196] Call Trace:
[   97.391967]  &lt;TASK&gt;
[   97.392647]  ? __warn+0xcc/0x180
[   97.393640]  ? kprobe_trace_self_tests_init+0x3f1/0x480
[   97.395181]  ? report_bug+0xbd/0x150
[   97.396234]  ? handle_bug+0x3e/0x60
[   97.397311]  ? exc_invalid_op+0x1a/0x50
[   97.398434]  ? asm_exc_invalid_op+0x1a/0x20
[   97.399652]  ? trace_kprobe_is_busy+0x20/0x20
[   97.400904]  ? tracing_reset_all_online_cpus+0x15/0x90
[   97.402304]  ? kprobe_trace_self_tests_init+0x3f1/0x480
[   97.403773]  ? init_kprobe_trace+0x50/0x50
[   97.404972]  do_one_initcall+0x112/0x240
[   97.406113]  do_initcall_level+0x95/0xb0
[   97.407286]  ? kernel_init+0x1a/0x1a0
[   97.408401]  do_initcalls+0x3f/0x70
[   97.409452]  kernel_init_freeable+0x16f/0x1e0
[   97.410662]  ? rest_init+0x1f0/0x1f0
[   97.411738]  kernel_init+0x1a/0x1a0
[   97.412788]  ret_from_fork+0x39/0x50
[   97.413817]  ? rest_init+0x1f0/0x1f0
[   97.414844]  ret_from_fork_asm+0x11/0x20
[   97.416285]  &lt;/TASK&gt;
[   97.417134] irq event stamp: 13437323
[   97.418376] hardirqs last  enabled at (13437337): [&lt;ffffffff8110bc0c&gt;] console_unlock+0x11c/0x150
[   97.421285] hardirqs last disabled at (13437370): [&lt;ffffffff8110bbf1&gt;] console_unlock+0x101/0x150
[   97.423838] softirqs last  enabled at (13437366): [&lt;ffffffff8108e17f&gt;] handle_softirqs+0x23f/0x2a0
[   97.426450] softirqs last disabled at (13437393): [&lt;ffffffff8108e346&gt;] __irq_exit_rcu+0x66/0xd0
[   97.428850] ---[ end trace 0000000000000000 ]---
And also, since we can not cleanup dynamic_event file, ftracetest are
failed too.
To avoid these issues, build these tests only as modules.
CVE-2024-40929:In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: check n_ssids before accessing the ssids
In some versions of cfg80211, the ssids poinet might be a valid one even
though n_ssids is 0. Accessing the pointer in this case will cuase an
out-of-bound access. Fix this by checking n_ssids first.
CVE-2024-40941:In the Linux kernel, the following vulnerability has been resolved:
wifi: iwlwifi: mvm: don't read past the mfuart notifcation
In case the firmware sends a notification that claims it has more data
than it has, we will read past that was allocated for the notification.
Remove the print of the buffer, we won't see it by default. If needed,
we can see the content with tracing.
This was reported by KFENCE.
CVE-2024-38618:In the Linux kernel, the following vulnerability has been resolved:
ALSA: timer: Set lower bound of start tick time
Currently ALSA timer doesn't have the lower limit of the start tick
time, and it allows a very small size, e.g. 1 tick with 1ns resolution
for hrtimer.  Such a situation may lead to an unexpected RCU stall,
where  the callback repeatedly queuing the expire update, as reported
by fuzzer.
This patch introduces a sanity check of the timer start tick time, so
that the system returns an error when a too small start size is set.
As of this patch, the lower limit is hard-coded to 100us, which is
small enough but can still work somehow.
CVE-2024-40968:In the Linux kernel, the following vulnerability has been resolved:
MIPS: Octeon: Add PCIe link status check
The standard PCIe configuration read-write interface is used to
access the configuration space of the peripheral PCIe devices
of the mips processor after the PCIe link surprise down, it can
generate kernel panic caused by &quot;Data bus error&quot;. So it is
necessary to add PCIe link status check for system protection.
When the PCIe link is down or in training, assigning a value
of 0 to the configuration address can prevent read-write behavior
to the configuration space of peripheral PCIe devices, thereby
preventing kernel panic.
CVE-2024-40912:In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: Fix deadlock in ieee80211_sta_ps_deliver_wakeup()
The ieee80211_sta_ps_deliver_wakeup() function takes sta-&gt;ps_lock to
synchronizes with ieee80211_tx_h_unicast_ps_buf() which is called from
softirq context. However using only spin_lock() to get sta-&gt;ps_lock in
ieee80211_sta_ps_deliver_wakeup() does not prevent softirq to execute
on this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try to
take this same lock ending in deadlock. Below is an example of rcu stall
that arises in such situation.
 rcu: INFO: rcu_sched self-detected stall on CPU
 rcu:    2-....: (42413413 ticks this GP) idle=b154/1/0x4000000000000000 softirq=1763/1765 fqs=21206996
 rcu:    (t=42586894 jiffies g=2057 q=362405 ncpus=4)
 CPU: 2 PID: 719 Comm: wpa_supplicant Tainted: G        W          6.4.0-02158-g1b062f552873 #742
 Hardware name: RPT (r1) (DT)
 pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : queued_spin_lock_slowpath+0x58/0x2d0
 lr : invoke_tx_handlers_early+0x5b4/0x5c0
 sp : ffff00001ef64660
 x29: ffff00001ef64660 x28: ffff000009bc1070 x27: ffff000009bc0ad8
 x26: ffff000009bc0900 x25: ffff00001ef647a8 x24: 0000000000000000
 x23: ffff000009bc0900 x22: ffff000009bc0900 x21: ffff00000ac0e000
 x20: ffff00000a279e00 x19: ffff00001ef646e8 x18: 0000000000000000
 x17: ffff800016468000 x16: ffff00001ef608c0 x15: 0010533c93f64f80
 x14: 0010395c9faa3946 x13: 0000000000000000 x12: 00000000fa83b2da
 x11: 000000012edeceea x10: ffff0000010fbe00 x9 : 0000000000895440
 x8 : 000000000010533c x7 : ffff00000ad8b740 x6 : ffff00000c350880
 x5 : 0000000000000007 x4 : 0000000000000001 x3 : 0000000000000000
 x2 : 0000000000000000 x1 : 0000000000000001 x0 : ffff00000ac0e0e8
 Call trace:
  queued_spin_lock_slowpath+0x58/0x2d0
  ieee80211_tx+0x80/0x12c
  ieee80211_tx_pending+0x110/0x278
  tasklet_action_common.constprop.0+0x10c/0x144
  tasklet_action+0x20/0x28
  _stext+0x11c/0x284
  ____do_softirq+0xc/0x14
  call_on_irq_stack+0x24/0x34
  do_softirq_own_stack+0x18/0x20
  do_softirq+0x74/0x7c
  __local_bh_enable_ip+0xa0/0xa4
  _ieee80211_wake_txqs+0x3b0/0x4b8
  __ieee80211_wake_queue+0x12c/0x168
  ieee80211_add_pending_skbs+0xec/0x138
  ieee80211_sta_ps_deliver_wakeup+0x2a4/0x480
  ieee80211_mps_sta_status_update.part.0+0xd8/0x11c
  ieee80211_mps_sta_status_update+0x18/0x24
  sta_apply_parameters+0x3bc/0x4c0
  ieee80211_change_station+0x1b8/0x2dc
  nl80211_set_station+0x444/0x49c
  genl_family_rcv_msg_doit.isra.0+0xa4/0xfc
  genl_rcv_msg+0x1b0/0x244
  netlink_rcv_skb+0x38/0x10c
  genl_rcv+0x34/0x48
  netlink_unicast+0x254/0x2bc
  netlink_sendmsg+0x190/0x3b4
  ____sys_sendmsg+0x1e8/0x218
  ___sys_sendmsg+0x68/0x8c
  __sys_sendmsg+0x44/0x84
  __arm64_sys_sendmsg+0x20/0x28
  do_el0_svc+0x6c/0xe8
  el0_svc+0x14/0x48
  el0t_64_sync_handler+0xb0/0xb4
  el0t_64_sync+0x14c/0x150
Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raise
on the same CPU that is holding the lock.
CVE-2024-40990:In the Linux kernel, the following vulnerability has been resolved:
RDMA/mlx5: Add check for srq max_sge attribute
max_sge attribute is passed by the user, and is inserted and used
unchecked, so verify that the value doesn't exceed maximum allowed value
before using it.
CVE-2024-40980:In the Linux kernel, the following vulnerability has been resolved:
drop_monitor: replace spin_lock by raw_spin_lock
trace_drop_common() is called with preemption disabled, and it acquires
a spin_lock. This is problematic for RT kernels because spin_locks are
sleeping locks in this configuration, which causes the following splat:
BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48
in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47
preempt_count: 1, expected: 0
RCU nest depth: 2, expected: 2
5 locks held by rcuc/47/449:
 #0: ff1100086ec30a60 ((softirq_ctrl.lock)){+.+.}-{2:2}, at: __local_bh_disable_ip+0x105/0x210
 #1: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: rt_spin_lock+0xbf/0x130
 #2: ffffffffb394a280 (rcu_read_lock){....}-{1:2}, at: __local_bh_disable_ip+0x11c/0x210
 #3: ffffffffb394a160 (rcu_callback){....}-{0:0}, at: rcu_do_batch+0x360/0xc70
 #4: ff1100086ee07520 (&amp;data-&gt;lock){+.+.}-{2:2}, at: trace_drop_common.constprop.0+0xb5/0x290
irq event stamp: 139909
hardirqs last  enabled at (139908): [&lt;ffffffffb1df2b33&gt;] _raw_spin_unlock_irqrestore+0x63/0x80
hardirqs last disabled at (139909): [&lt;ffffffffb19bd03d&gt;] trace_drop_common.constprop.0+0x26d/0x290
softirqs last  enabled at (139892): [&lt;ffffffffb07a1083&gt;] __local_bh_enable_ip+0x103/0x170
softirqs last disabled at (139898): [&lt;ffffffffb0909b33&gt;] rcu_cpu_kthread+0x93/0x1f0
Preemption disabled at:
[&lt;ffffffffb1de786b&gt;] rt_mutex_slowunlock+0xab/0x2e0
CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7
Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022
Call Trace:
 &lt;TASK&gt;
 dump_stack_lvl+0x8c/0xd0
 dump_stack+0x14/0x20
 __might_resched+0x21e/0x2f0
 rt_spin_lock+0x5e/0x130
 ? trace_drop_common.constprop.0+0xb5/0x290
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 trace_drop_common.constprop.0+0xb5/0x290
 ? preempt_count_sub+0x1c/0xd0
 ? _raw_spin_unlock_irqrestore+0x4a/0x80
 ? __pfx_trace_drop_common.constprop.0+0x10/0x10
 ? rt_mutex_slowunlock+0x26a/0x2e0
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 ? __pfx_rt_mutex_slowunlock+0x10/0x10
 ? skb_queue_purge_reason.part.0+0x1bf/0x230
 trace_kfree_skb_hit+0x15/0x20
 trace_kfree_skb+0xe9/0x150
 kfree_skb_reason+0x7b/0x110
 skb_queue_purge_reason.part.0+0x1bf/0x230
 ? __pfx_skb_queue_purge_reason.part.0+0x10/0x10
 ? mark_lock.part.0+0x8a/0x520
...
trace_drop_common() also disables interrupts, but this is a minor issue
because we could easily replace it with a local_lock.
Replace the spin_lock with raw_spin_lock to avoid sleeping in atomic
context.
CVE-2024-34777:In the Linux kernel, the following vulnerability has been resolved:
dma-mapping: benchmark: fix node id validation
While validating node ids in map_benchmark_ioctl(), node_possible() may
be provided with invalid argument outside of [0,MAX_NUMNODES-1] range
leading to:
BUG: KASAN: wild-memory-access in map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
Read of size 8 at addr 1fffffff8ccb6398 by task dma_map_benchma/971
CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
Call Trace:
 &lt;TASK&gt;
dump_stack_lvl (lib/dump_stack.c:117)
kasan_report (mm/kasan/report.c:603)
kasan_check_range (mm/kasan/generic.c:189)
variable_test_bit (arch/x86/include/asm/bitops.h:227) [inline]
arch_test_bit (arch/x86/include/asm/bitops.h:239) [inline]
_test_bit at (include/asm-generic/bitops/instrumented-non-atomic.h:142) [inline]
node_state (include/linux/nodemask.h:423) [inline]
map_benchmark_ioctl (kernel/dma/map_benchmark.c:214)
full_proxy_unlocked_ioctl (fs/debugfs/file.c:333)
__x64_sys_ioctl (fs/ioctl.c:890)
do_syscall_64 (arch/x86/entry/common.c:83)
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Compare node ids with sane bounds first. NUMA_NO_NODE is considered a
special valid case meaning that benchmarking kthreads won't be bound to a
cpuset of a given node.
Found by Linux Verification Center (linuxtesting.org).
CVE-2022-48814:In the Linux kernel, the following vulnerability has been resolved:
net: dsa: seville: register the mdiobus under devres
As explained in commits:
74b6d7d13307 (&quot;net: dsa: realtek: register the MDIO bus under devres&quot;)
5135e96a3dd2 (&quot;net: dsa: don't allocate the slave_mii_bus using devres&quot;)
mdiobus_free() will panic when called from devm_mdiobus_free() &lt;-
devres_release_all() &lt;- __device_release_driver(), and that mdiobus was
not previously unregistered.
The Seville VSC9959 switch is a platform device, so the initial set of
constraints that I thought would cause this (I2C or SPI buses which call
-&gt;remove on -&gt;shutdown) do not apply. But there is one more which
applies here.
If the DSA master itself is on a bus that calls -&gt;remove from -&gt;shutdown
(like dpaa2-eth, which is on the fsl-mc bus), there is a device link
between the switch and the DSA master, and device_links_unbind_consumers()
will unbind the seville switch driver on shutdown.
So the same treatment must be applied to all DSA switch drivers, which
is: either use devres for both the mdiobus allocation and registration,
or don't use devres at all.
The seville driver has a code structure that could accommodate both the
mdiobus_unregister and mdiobus_free calls, but it has an external
dependency upon mscc_miim_setup() from mdio-mscc-miim.c, which calls
devm_mdiobus_alloc_size() on its behalf. So rather than restructuring
that, and exporting yet one more symbol mscc_miim_teardown(), let's work
with devres and replace of_mdiobus_register with the devres variant.
When we use all-devres, we can ensure that devres doesn't free a
still-registered bus (it either runs both callbacks, or none).
CVE-2024-38568:In the Linux kernel, the following vulnerability has been resolved:
drivers/perf: hisi: hns3: 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 HNS3_PMU_MAX_HW_EVENTS, 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-35837:In the Linux kernel, the following vulnerability has been resolved:
net: mvpp2: clear BM pool before initialization
Register value persist after booting the kernel using
kexec which results in kernel panic. Thus clear the
BM pool registers before initialisation to fix the issue.
CVE-2024-41009:In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix overrunning reservations in ringbuf
The BPF ring buffer internally is implemented as a power-of-2 sized circular
buffer, with two logical and ever-increasing counters: consumer_pos is the
consumer counter to show which logical position the consumer consumed the
data, and producer_pos which is the producer counter denoting the amount of
data reserved by all producers.
Each time a record is reserved, the producer that &quot;owns&quot; the record will
successfully advance producer counter. In user space each time a record is
read, the consumer of the data advanced the consumer counter once it finished
processing. Both counters are stored in separate pages so that from user
space, the producer counter is read-only and the consumer counter is read-write.
One aspect that simplifies and thus speeds up the implementation of both
producers and consumers is how the data area is mapped twice contiguously
back-to-back in the virtual memory, allowing to not take any special measures
for samples that have to wrap around at the end of the circular buffer data
area, because the next page after the last data page would be first data page
again, and thus the sample will still appear completely contiguous in virtual
memory.
Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header for
book-keeping the length and offset, and is inaccessible to the BPF program.
Helpers like bpf_ringbuf_reserve() return `(void *)hdr + BPF_RINGBUF_HDR_SZ`
for the BPF program to use. Bing-Jhong and Muhammad reported that it is however
possible to make a second allocated memory chunk overlapping with the first
chunk and as a result, the BPF program is now able to edit first chunk's
header.
For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with size
of 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call to
bpf_ringbuf_reserve() is made. This will allocate a chunk A, which is in
[0x0,0x3008], and the BPF program is able to edit [0x8,0x3008]. Now, lets
allocate a chunk B with size 0x3000. This will succeed because consumer_pos
was edited ahead of time to pass the `new_prod_pos - cons_pos &gt; rb-&gt;mask`
check. Chunk B will be in range [0x3008,0x6010], and the BPF program is able
to edit [0x3010,0x6010]. Due to the ring buffer memory layout mentioned
earlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same data
pages. This means that chunk B at [0x4000,0x4008] is chunk A's header.
bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header's pg_off to then
locate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunk
B modified chunk A's header, then bpf_ringbuf_commit() refers to the wrong
page and could cause a crash.
Fix it by calculating the oldest pending_pos and check whether the range
from the oldest outstanding record to the newest would span beyond the ring
buffer size. If that is the case, then reject the request. We've tested with
the ring buffer benchmark in BPF selftests (./benchs/run_bench_ringbufs.sh)
before/after the fix and while it seems a bit slower on some benchmarks, it
is still not significantly enough to matter.
CVE-2024-35931:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Skip do PCI error slot reset during RAS recovery
Why:
    The PCI error slot reset maybe triggered after inject ue to UMC multi times, this
    caused system hang.
    [  557.371857] amdgpu 0000:af:00.0: amdgpu: GPU reset succeeded, trying to resume
    [  557.373718] [drm] PCIE GART of 512M enabled.
    [  557.373722] [drm] PTB located at 0x0000031FED700000
    [  557.373788] [drm] VRAM is lost due to GPU reset!
    [  557.373789] [drm] PSP is resuming...
    [  557.547012] mlx5_core 0000:55:00.0: mlx5_pci_err_detected Device state = 1 pci_status: 0. Exit, result = 3, need reset
    [  557.547067] [drm] PCI error: detected callback, state(1)!!
    [  557.547069] [drm] No support for XGMI hive yet...
    [  557.548125] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 0. Enter
    [  557.607763] mlx5_core 0000:55:00.0: wait vital counter value 0x16b5b after 1 iterations
    [  557.607777] mlx5_core 0000:55:00.0: mlx5_pci_slot_reset Device state = 1 pci_status: 1. Exit, err = 0, result = 5, recovered
    [  557.610492] [drm] PCI error: slot reset callback!!
    ...
    [  560.689382] amdgpu 0000:3f:00.0: amdgpu: GPU reset(2) succeeded!
    [  560.689546] amdgpu 0000:5a:00.0: amdgpu: GPU reset(2) succeeded!
    [  560.689562] general protection fault, probably for non-canonical address 0x5f080b54534f611f: 0000 [#1] SMP NOPTI
    [  560.701008] CPU: 16 PID: 2361 Comm: kworker/u448:9 Tainted: G           OE     5.15.0-91-generic #101-Ubuntu
    [  560.712057] Hardware name: Microsoft C278A/C278A, BIOS C2789.5.BS.1C11.AG.1 11/08/2023
    [  560.720959] Workqueue: amdgpu-reset-hive amdgpu_ras_do_recovery [amdgpu]
    [  560.728887] RIP: 0010:amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
    [  560.736891] Code: ff 41 89 c6 e9 1b ff ff ff 44 0f b6 45 b0 e9 4f ff ff ff be 01 00 00 00 4c 89 e7 e8 76 c9 8b ff 44 0f b6 45 b0 e9 3c fd ff ff &lt;48&gt; 83 ba 18 02 00 00 00 0f 84 6a f8 ff ff 48 8d 7a 78 be 01 00 00
    [  560.757967] RSP: 0018:ffa0000032e53d80 EFLAGS: 00010202
    [  560.763848] RAX: ffa00000001dfd10 RBX: ffa0000000197090 RCX: ffa0000032e53db0
    [  560.771856] RDX: 5f080b54534f5f07 RSI: 0000000000000000 RDI: ff11000128100010
    [  560.779867] RBP: ffa0000032e53df0 R08: 0000000000000000 R09: ffffffffffe77f08
    [  560.787879] R10: 0000000000ffff0a R11: 0000000000000001 R12: 0000000000000000
    [  560.795889] R13: ffa0000032e53e00 R14: 0000000000000000 R15: 0000000000000000
    [  560.803889] FS:  0000000000000000(0000) GS:ff11007e7e800000(0000) knlGS:0000000000000000
    [  560.812973] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    [  560.819422] CR2: 000055a04c118e68 CR3: 0000000007410005 CR4: 0000000000771ee0
    [  560.827433] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
    [  560.835433] DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400
    [  560.843444] PKRU: 55555554
    [  560.846480] Call Trace:
    [  560.849225]  &lt;TASK&gt;
    [  560.851580]  ? show_trace_log_lvl+0x1d6/0x2ea
    [  560.856488]  ? show_trace_log_lvl+0x1d6/0x2ea
    [  560.861379]  ? amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
    [  560.867778]  ? show_regs.part.0+0x23/0x29
    [  560.872293]  ? __die_body.cold+0x8/0xd
    [  560.876502]  ? die_addr+0x3e/0x60
    [  560.880238]  ? exc_general_protection+0x1c5/0x410
    [  560.885532]  ? asm_exc_general_protection+0x27/0x30
    [  560.891025]  ? amdgpu_device_gpu_recover.cold+0xbf1/0xcf5 [amdgpu]
    [  560.898323]  amdgpu_ras_do_recovery+0x1b2/0x210 [amdgpu]
    [  560.904520]  process_one_work+0x228/0x3d0
How:
    In RAS recovery, mode-1 reset is issued from RAS fatal error handling and expected
    all the nodes in a hive to be reset. no need to issue another mode-1 during this procedure.
CVE-2024-39494:In the Linux kernel, the following vulnerability has been resolved:ima: Fix use-after-free on a dentry s dname.name-&gt;d_name.name can change on rename and the earlier value can be freed;there are conditions sufficient to stabilize it (-&gt;d_lock on dentry,-&gt;d_lock on its parent, -&gt;i_rwsem exclusive on the parent s inode,rename_lock), but none of those are met at any of the sites. Take a stablesnapshot of the name instead.
CVE-2024-41007:In the Linux kernel, the following vulnerability has been resolved:
tcp: avoid too many retransmit packets
If a TCP socket is using TCP_USER_TIMEOUT, and the other peer
retracted its window to zero, tcp_retransmit_timer() can
retransmit a packet every two jiffies (2 ms for HZ=1000),
for about 4 minutes after TCP_USER_TIMEOUT has 'expired'.
The fix is to make sure tcp_rtx_probe0_timed_out() takes
icsk-&gt;icsk_user_timeout into account.
Before blamed commit, the socket would not timeout after
icsk-&gt;icsk_user_timeout, but would use standard exponential
backoff for the retransmits.
Also worth noting that before commit e89688e3e978 (&quot;net: tcp:
fix unexcepted socket die when snd_wnd is 0&quot;), the issue
would last 2 minutes instead of 4.
CVE-2024-40947:In the Linux kernel, the following vulnerability has been resolved:
ima: Avoid blocking in RCU read-side critical section
A panic happens in ima_match_policy:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000010
PGD 42f873067 P4D 0
Oops: 0000 [#1] SMP NOPTI
CPU: 5 PID: 1286325 Comm: kubeletmonit.sh
Kdump: loaded Tainted: P
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
               BIOS 0.0.0 02/06/2015
RIP: 0010:ima_match_policy+0x84/0x450
Code: 49 89 fc 41 89 cf 31 ed 89 44 24 14 eb 1c 44 39
      7b 18 74 26 41 83 ff 05 74 20 48 8b 1b 48 3b 1d
      f2 b9 f4 00 0f 84 9c 01 00 00 &lt;44&gt; 85 73 10 74 ea
      44 8b 6b 14 41 f6 c5 01 75 d4 41 f6 c5 02 74 0f
RSP: 0018:ff71570009e07a80 EFLAGS: 00010207
RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200
RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000
RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739
R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970
R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001
FS:  00007f5195b51740(0000)
GS:ff3e278b12d40000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 ima_get_action+0x22/0x30
 process_measurement+0xb0/0x830
 ? page_add_file_rmap+0x15/0x170
 ? alloc_set_pte+0x269/0x4c0
 ? prep_new_page+0x81/0x140
 ? simple_xattr_get+0x75/0xa0
 ? selinux_file_open+0x9d/0xf0
 ima_file_check+0x64/0x90
 path_openat+0x571/0x1720
 do_filp_open+0x9b/0x110
 ? page_counter_try_charge+0x57/0xc0
 ? files_cgroup_alloc_fd+0x38/0x60
 ? __alloc_fd+0xd4/0x250
 ? do_sys_open+0x1bd/0x250
 do_sys_open+0x1bd/0x250
 do_syscall_64+0x5d/0x1d0
 entry_SYSCALL_64_after_hwframe+0x65/0xca
Commit c7423dbdbc9e (&quot;ima: Handle -ESTALE returned by
ima_filter_rule_match()&quot;) introduced call to ima_lsm_copy_rule within a
RCU read-side critical section which contains kmalloc with GFP_KERNEL.
This implies a possible sleep and violates limitations of RCU read-side
critical sections on non-PREEMPT systems.
Sleeping within RCU read-side critical section might cause
synchronize_rcu() returning early and break RCU protection, allowing a
UAF to happen.
The root cause of this issue could be described as follows:
|	Thread A	|	Thread B	|
|			|ima_match_policy	|
|			|  rcu_read_lock	|
|ima_lsm_update_rule	|			|
|  synchronize_rcu	|			|
|			|    kmalloc(GFP_KERNEL)|
|			|      sleep		|
==&gt; synchronize_rcu returns early
|  kfree(entry)		|			|
|			|    entry = entry-&gt;next|
==&gt; UAF happens and entry now becomes NULL (or could be anything).
|			|    entry-&gt;action	|
==&gt; Accessing entry might cause panic.
To fix this issue, we are converting all kmalloc that is called within
RCU read-side critical section to use GFP_ATOMIC.
[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case]
CVE-2022-48844:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: Fix leaking sent_cmd skb
sent_cmd memory is not freed before freeing hci_dev causing it to leak
it contents.
CVE-2024-40982:In the Linux kernel, the following vulnerability has been resolved:
ssb: Fix potential NULL pointer dereference in ssb_device_uevent()
The ssb_device_uevent() function first attempts to convert the 'dev' pointer
to 'struct ssb_device *'. However, it mistakenly dereferences 'dev' before
performing the NULL check, potentially leading to a NULL pointer
dereference if 'dev' is NULL.
To fix this issue, move the NULL check before dereferencing the 'dev' pointer,
ensuring that the pointer is valid before attempting to use it.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-39475:In the Linux kernel, the following vulnerability has been resolved:
fbdev: savage: Handle err return when savagefb_check_var failed
The commit 04e5eac8f3ab(&quot;fbdev: savage: Error out if pixclock equals zero&quot;)
checks the value of pixclock to avoid divide-by-zero error. However
the function savagefb_probe doesn't handle the error return of
savagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.
CVE-2024-40956:In the Linux kernel, the following vulnerability has been resolved:
dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_list
Use list_for_each_entry_safe() to allow iterating through the list and
deleting the entry in the iteration process. The descriptor is freed via
idxd_desc_complete() and there's a slight chance may cause issue for
the list iterator when the descriptor is reused by another thread
without it being deleted from the list.
CVE-2024-40981:In the Linux kernel, the following vulnerability has been resolved:
batman-adv: bypass empty buckets in batadv_purge_orig_ref()
Many syzbot reports are pointing to soft lockups in
batadv_purge_orig_ref() [1]
Root cause is unknown, but we can avoid spending too much
time there and perhaps get more interesting reports.
[1]
watchdog: BUG: soft lockup - CPU#0 stuck for 27s! [kworker/u4:6:621]
Modules linked in:
irq event stamp: 6182794
 hardirqs last  enabled at (6182793): [&lt;ffff8000801dae10&gt;] __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
 hardirqs last disabled at (6182794): [&lt;ffff80008ad66a78&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
 hardirqs last disabled at (6182794): [&lt;ffff80008ad66a78&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
 softirqs last  enabled at (6182792): [&lt;ffff80008aab71c4&gt;] spin_unlock_bh include/linux/spinlock.h:396 [inline]
 softirqs last  enabled at (6182792): [&lt;ffff80008aab71c4&gt;] batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
 softirqs last disabled at (6182790): [&lt;ffff80008aab61dc&gt;] spin_lock_bh include/linux/spinlock.h:356 [inline]
 softirqs last disabled at (6182790): [&lt;ffff80008aab61dc&gt;] batadv_purge_orig_ref+0x164/0x1228 net/batman-adv/originator.c:1271
CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
Workqueue: bat_events batadv_purge_orig
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : should_resched arch/arm64/include/asm/preempt.h:79 [inline]
 pc : __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:388
 lr : __local_bh_enable_ip+0x224/0x44c kernel/softirq.c:386
sp : ffff800099007970
x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000
x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001
x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4
x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0
x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001
x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003
x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000
x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000
x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000
Call trace:
  __daif_local_irq_enable arch/arm64/include/asm/irqflags.h:27 [inline]
  arch_local_irq_enable arch/arm64/include/asm/irqflags.h:49 [inline]
  __local_bh_enable_ip+0x228/0x44c kernel/softirq.c:386
  __raw_spin_unlock_bh include/linux/spinlock_api_smp.h:167 [inline]
  _raw_spin_unlock_bh+0x3c/0x4c kernel/locking/spinlock.c:210
  spin_unlock_bh include/linux/spinlock.h:396 [inline]
  batadv_purge_orig_ref+0x114c/0x1228 net/batman-adv/originator.c:1287
  batadv_purge_orig+0x20/0x70 net/batman-adv/originator.c:1300
  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
Sending NMI from CPU 0 to CPUs 1:
NMI backtrace for cpu 1
CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : arch_local_irq_enable+0x8/0xc arch/arm64/include/asm/irqflags.h:51
 lr : default_idle_call+0xf8/0x128 kernel/sched/idle.c:103
sp : ffff800093a17d30
x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4
x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002
x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000
x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396
x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001
---truncated---
CVE-2024-40904:In the Linux kernel, the following vulnerability has been resolved:
USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messages
The syzbot fuzzer found that the interrupt-URB completion callback in
the cdc-wdm driver was taking too long, and the driver's immediate
resubmission of interrupt URBs with -EPROTO status combined with the
dummy-hcd emulation to cause a CPU lockup:
cdc_wdm 1-1:1.0: nonzero urb status received: -71
cdc_wdm 1-1:1.0: wdm_int_callback - 0 bytes
watchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]
CPU#0 Utilization every 4s during lockup:
	#1:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#2:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#3:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#4:  98% system,	  0% softirq,	  3% hardirq,	  0% idle
	#5:  98% system,	  1% softirq,	  3% hardirq,	  0% idle
Modules linked in:
irq event stamp: 73096
hardirqs last  enabled at (73095): [&lt;ffff80008037bc00&gt;] console_emit_next_record kernel/printk/printk.c:2935 [inline]
hardirqs last  enabled at (73095): [&lt;ffff80008037bc00&gt;] console_flush_all+0x650/0xb74 kernel/printk/printk.c:2994
hardirqs last disabled at (73096): [&lt;ffff80008af10b00&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
hardirqs last disabled at (73096): [&lt;ffff80008af10b00&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
softirqs last  enabled at (73048): [&lt;ffff8000801ea530&gt;] softirq_handle_end kernel/softirq.c:400 [inline]
softirqs last  enabled at (73048): [&lt;ffff8000801ea530&gt;] handle_softirqs+0xa60/0xc34 kernel/softirq.c:582
softirqs last disabled at (73043): [&lt;ffff800080020de8&gt;] __do_softirq+0x14/0x20 kernel/softirq.c:588
CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Testing showed that the problem did not occur if the two error
messages -- the first two lines above -- were removed; apparently adding
material to the kernel log takes a surprisingly large amount of time.
In any case, the best approach for preventing these lockups and to
avoid spamming the log with thousands of error messages per second is
to ratelimit the two dev_err() calls.  Therefore we replace them with
dev_err_ratelimited().
CVE-2024-39509:In the Linux kernel, the following vulnerability has been resolved:
HID: core: remove unnecessary WARN_ON() in implement()
Syzkaller hit a warning [1] in a call to implement() when trying
to write a value into a field of smaller size in an output report.
Since implement() already has a warn message printed out with the
help of hid_warn() and value in question gets trimmed with:
	...
	value &amp;= m;
	...
WARN_ON may be considered superfluous. Remove it to suppress future
syzkaller triggers.
[1]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 implement drivers/hid/hid-core.c:1451 [inline]
WARNING: CPU: 0 PID: 5084 at drivers/hid/hid-core.c:1451 hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
Modules linked in:
CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
RIP: 0010:implement drivers/hid/hid-core.c:1451 [inline]
RIP: 0010:hid_output_report+0x548/0x760 drivers/hid/hid-core.c:1863
...
Call Trace:
 &lt;TASK&gt;
 __usbhid_submit_report drivers/hid/usbhid/hid-core.c:591 [inline]
 usbhid_submit_report+0x43d/0x9e0 drivers/hid/usbhid/hid-core.c:636
 hiddev_ioctl+0x138b/0x1f00 drivers/hid/usbhid/hiddev.c:726
 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
...
CVE-2023-52679:In the Linux kernel, the following vulnerability has been resolved:
of: Fix double free in of_parse_phandle_with_args_map
In of_parse_phandle_with_args_map() the inner loop that
iterates through the map entries calls of_node_put(new)
to free the reference acquired by the previous iteration
of the inner loop. This assumes that the value of &quot;new&quot; is
NULL on the first iteration of the inner loop.
Make sure that this is true in all iterations of the outer
loop by setting &quot;new&quot; to NULL after its value is assigned to &quot;cur&quot;.
Extend the unittest to detect the double free and add an additional
test case that actually triggers this path.
CVE-2024-38619:In the Linux kernel, the following vulnerability has been resolved:
usb-storage: alauda: Check whether the media is initialized
The member &quot;uzonesize&quot; of struct alauda_info will remain 0
if alauda_init_media() fails, potentially causing divide errors
in alauda_read_data() and alauda_write_lba().
- Add a member &quot;media_initialized&quot; to struct alauda_info.
- Change a condition in alauda_check_media() to ensure the
  first initialization.
- Add an error check for the return value of alauda_init_media().
CVE-2022-48859:In the Linux kernel, the following vulnerability has been resolved:
net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addr
This node pointer is returned by of_find_compatible_node() with
refcount incremented. Calling of_node_put() to aovid the refcount leak.
CVE-2024-40915:In the Linux kernel, the following vulnerability has been resolved:
riscv: rewrite __kernel_map_pages() to fix sleeping in invalid context
__kernel_map_pages() is a debug function which clears the valid bit in page
table entry for deallocated pages to detect illegal memory accesses to
freed pages.
This function set/clear the valid bit using __set_memory(). __set_memory()
acquires init_mm's semaphore, and this operation may sleep. This is
problematic, because  __kernel_map_pages() can be called in atomic context,
and thus is illegal to sleep. An example warning that this causes:
BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1578
in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreadd
preempt_count: 2, expected: 0
CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37
Hardware name: riscv-virtio,qemu (DT)
Call Trace:
[&lt;ffffffff800060dc&gt;] dump_backtrace+0x1c/0x24
[&lt;ffffffff8091ef6e&gt;] show_stack+0x2c/0x38
[&lt;ffffffff8092baf8&gt;] dump_stack_lvl+0x5a/0x72
[&lt;ffffffff8092bb24&gt;] dump_stack+0x14/0x1c
[&lt;ffffffff8003b7ac&gt;] __might_resched+0x104/0x10e
[&lt;ffffffff8003b7f4&gt;] __might_sleep+0x3e/0x62
[&lt;ffffffff8093276a&gt;] down_write+0x20/0x72
[&lt;ffffffff8000cf00&gt;] __set_memory+0x82/0x2fa
[&lt;ffffffff8000d324&gt;] __kernel_map_pages+0x5a/0xd4
[&lt;ffffffff80196cca&gt;] __alloc_pages_bulk+0x3b2/0x43a
[&lt;ffffffff8018ee82&gt;] __vmalloc_node_range+0x196/0x6ba
[&lt;ffffffff80011904&gt;] copy_process+0x72c/0x17ec
[&lt;ffffffff80012ab4&gt;] kernel_clone+0x60/0x2fe
[&lt;ffffffff80012f62&gt;] kernel_thread+0x82/0xa0
[&lt;ffffffff8003552c&gt;] kthreadd+0x14a/0x1be
[&lt;ffffffff809357de&gt;] ret_from_fork+0xe/0x1c
Rewrite this function with apply_to_existing_page_range(). It is fine to
not have any locking, because __kernel_map_pages() works with pages being
allocated/deallocated and those pages are not changed by anyone else in the
meantime.
CVE-2021-47205:In the Linux kernel, the following vulnerability has been resolved:
clk: sunxi-ng: Unregister clocks/resets when unbinding
Currently, unbinding a CCU driver unmaps the device's MMIO region, while
leaving its clocks/resets and their providers registered. This can cause
a page fault later when some clock operation tries to perform MMIO. Fix
this by separating the CCU initialization from the memory allocation,
and then using a devres callback to unregister the clocks and resets.
This also fixes a memory leak of the `struct ccu_reset`, and uses the
correct owner (the specific platform driver) for the clocks and resets.
Early OF clock providers are never unregistered, and limited error
handling is possible, so they are mostly unchanged. The error reporting
is made more consistent by moving the message inside of_sunxi_ccu_probe.
CVE-2024-38611:In the Linux kernel, the following vulnerability has been resolved:
media: i2c: et8ek8: Don't strip remove function when driver is builtin
Using __exit for the remove function results in the remove callback
being discarded with CONFIG_VIDEO_ET8EK8=y. When such a device gets
unbound (e.g. using sysfs or hotplug), the driver is just removed
without the cleanup being performed. This results in resource leaks. Fix
it by compiling in the remove callback unconditionally.
This also fixes a W=1 modpost warning:
	WARNING: modpost: drivers/media/i2c/et8ek8/et8ek8: section mismatch in reference: et8ek8_i2c_driver+0x10 (section: .data) -&gt; et8ek8_remove (section: .exit.text)
CVE-2024-41011:In the Linux kernel, the following vulnerability has been resolved:
drm/amdkfd: don't allow mapping the MMIO HDP page with large pages
We don't get the right offset in that case.  The GPU has
an unused 4K area of the register BAR space into which you can
remap registers.  We remap the HDP flush registers into this
space to allow userspace (CPU or GPU) to flush the HDP when it
updates VRAM.  However, on systems with &gt;4K pages, we end up
exposing PAGE_SIZE of MMIO space.
CVE-2024-40988:In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: fix UBSAN warning in kv_dpm.c
Adds bounds check for sumo_vid_mapping_entry.
CVE-2024-42090:In the Linux kernel, the following vulnerability has been resolved:
pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFER
In create_pinctrl(), pinctrl_maps_mutex is acquired before calling
add_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()
calls pinctrl_free(). However, pinctrl_free() attempts to acquire
pinctrl_maps_mutex, which is already held by create_pinctrl(), leading to
a potential deadlock.
This patch resolves the issue by releasing pinctrl_maps_mutex before
calling pinctrl_free(), preventing the deadlock.
This bug was discovered and resolved using Coverity Static Analysis
Security Testing (SAST) by Synopsys, Inc.
CVE-2024-41069:In the Linux kernel, the following vulnerability has been resolved:
ASoC: topology: Fix references to freed memory
Most users after parsing a topology file, release memory used by it, so
having pointer references directly into topology file contents is wrong.
Use devm_kmemdup(), to allocate memory as needed.
CVE-2024-38627:In the Linux kernel, the following vulnerability has been resolved:
stm class: Fix a double free in stm_register_device()
The put_device(&amp;stm-&gt;dev) call will trigger stm_device_release() which
frees &quot;stm&quot; so the vfree(stm) on the next line is a double free.
CVE-2024-38561:In the Linux kernel, the following vulnerability has been resolved:
kunit: Fix kthread reference
There is a race condition when a kthread finishes after the deadline and
before the call to kthread_stop(), which may lead to use after free.
CVE-2021-47382:In the Linux kernel, the following vulnerability has been resolved:
s390/qeth: fix deadlock during failing recovery
Commit 0b9902c1fcc5 (&quot;s390/qeth: fix deadlock during recovery&quot;) removed
taking discipline_mutex inside qeth_do_reset(), fixing potential
deadlocks. An error path was missed though, that still takes
discipline_mutex and thus has the original deadlock potential.
Intermittent deadlocks were seen when a qeth channel path is configured
offline, causing a race between qeth_do_reset and ccwgroup_remove.
Call qeth_set_offline() directly in the qeth_do_reset() error case and
then a new variant of ccwgroup_set_offline(), without taking
discipline_mutex.
CVE-2024-41040:In the Linux kernel, the following vulnerability has been resolved:
net/sched: Fix UAF when resolving a clash
KASAN reports the following UAF:
 BUG: KASAN: slab-use-after-free in tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
 Read of size 1 at addr ffff888c07603600 by task handler130/6469
 Call Trace:
  &lt;IRQ&gt;
  dump_stack_lvl+0x48/0x70
  print_address_description.constprop.0+0x33/0x3d0
  print_report+0xc0/0x2b0
  kasan_report+0xd0/0x120
  __asan_load1+0x6c/0x80
  tcf_ct_flow_table_process_conn+0x12b/0x380 [act_ct]
  tcf_ct_act+0x886/0x1350 [act_ct]
  tcf_action_exec+0xf8/0x1f0
  fl_classify+0x355/0x360 [cls_flower]
  __tcf_classify+0x1fd/0x330
  tcf_classify+0x21c/0x3c0
  sch_handle_ingress.constprop.0+0x2c5/0x500
  __netif_receive_skb_core.constprop.0+0xb25/0x1510
  __netif_receive_skb_list_core+0x220/0x4c0
  netif_receive_skb_list_internal+0x446/0x620
  napi_complete_done+0x157/0x3d0
  gro_cell_poll+0xcf/0x100
  __napi_poll+0x65/0x310
  net_rx_action+0x30c/0x5c0
  __do_softirq+0x14f/0x491
  __irq_exit_rcu+0x82/0xc0
  irq_exit_rcu+0xe/0x20
  common_interrupt+0xa1/0xb0
  &lt;/IRQ&gt;
  &lt;TASK&gt;
  asm_common_interrupt+0x27/0x40
 Allocated by task 6469:
  kasan_save_stack+0x38/0x70
  kasan_set_track+0x25/0x40
  kasan_save_alloc_info+0x1e/0x40
  __kasan_krealloc+0x133/0x190
  krealloc+0xaa/0x130
  nf_ct_ext_add+0xed/0x230 [nf_conntrack]
  tcf_ct_act+0x1095/0x1350 [act_ct]
  tcf_action_exec+0xf8/0x1f0
  fl_classify+0x355/0x360 [cls_flower]
  __tcf_classify+0x1fd/0x330
  tcf_classify+0x21c/0x3c0
  sch_handle_ingress.constprop.0+0x2c5/0x500
  __netif_receive_skb_core.constprop.0+0xb25/0x1510
  __netif_receive_skb_list_core+0x220/0x4c0
  netif_receive_skb_list_internal+0x446/0x620
  napi_complete_done+0x157/0x3d0
  gro_cell_poll+0xcf/0x100
  __napi_poll+0x65/0x310
  net_rx_action+0x30c/0x5c0
  __do_softirq+0x14f/0x491
 Freed by task 6469:
  kasan_save_stack+0x38/0x70
  kasan_set_track+0x25/0x40
  kasan_save_free_info+0x2b/0x60
  ____kasan_slab_free+0x180/0x1f0
  __kasan_slab_free+0x12/0x30
  slab_free_freelist_hook+0xd2/0x1a0
  __kmem_cache_free+0x1a2/0x2f0
  kfree+0x78/0x120
  nf_conntrack_free+0x74/0x130 [nf_conntrack]
  nf_ct_destroy+0xb2/0x140 [nf_conntrack]
  __nf_ct_resolve_clash+0x529/0x5d0 [nf_conntrack]
  nf_ct_resolve_clash+0xf6/0x490 [nf_conntrack]
  __nf_conntrack_confirm+0x2c6/0x770 [nf_conntrack]
  tcf_ct_act+0x12ad/0x1350 [act_ct]
  tcf_action_exec+0xf8/0x1f0
  fl_classify+0x355/0x360 [cls_flower]
  __tcf_classify+0x1fd/0x330
  tcf_classify+0x21c/0x3c0
  sch_handle_ingress.constprop.0+0x2c5/0x500
  __netif_receive_skb_core.constprop.0+0xb25/0x1510
  __netif_receive_skb_list_core+0x220/0x4c0
  netif_receive_skb_list_internal+0x446/0x620
  napi_complete_done+0x157/0x3d0
  gro_cell_poll+0xcf/0x100
  __napi_poll+0x65/0x310
  net_rx_action+0x30c/0x5c0
  __do_softirq+0x14f/0x491
The ct may be dropped if a clash has been resolved but is still passed to
the tcf_ct_flow_table_process_conn function for further usage. This issue
can be fixed by retrieving ct from skb again after confirming conntrack.
CVE-2024-40999:In the Linux kernel, the following vulnerability has been resolved:
net: ena: Add validation for completion descriptors consistency
Validate that `first` flag is set only for the first
descriptor in multi-buffer packets.
In case of an invalid descriptor, a reset will occur.
A new reset reason for RX data corruption has been added.
CVE-2024-41019:In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Validate ff offset
This adds sanity checks for ff offset. There is a check
on rt-&gt;first_free at first, but walking through by ff
without any check. If the second ff is a large offset.
We may encounter an out-of-bound read.
CVE-2024-40959:In the Linux kernel, the following vulnerability has been resolved:
xfrm6: check ip6_dst_idev() return value in xfrm6_get_saddr()
ip6_dst_idev() can return NULL, xfrm6_get_saddr() must act accordingly.
syzbot reported:
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: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024
Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker
 RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64
Code: df 48 89 fa 48 c1 ea 03 80 3c 02 00 0f 85 97 00 00 00 4c 8b ab d8 00 00 00 48 b8 00 00 00 00 00 fc ff df 4c 89 ea 48 c1 ea 03 &lt;80&gt; 3c 02 00 0f 85 86 00 00 00 4d 8b 6d 00 e8 ca 13 47 01 48 b8 00
RSP: 0018:ffffc90000117378 EFLAGS: 00010246
RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7
RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98
RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000
R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
FS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  xfrm_get_saddr net/xfrm/xfrm_policy.c:2452 [inline]
  xfrm_tmpl_resolve_one net/xfrm/xfrm_policy.c:2481 [inline]
  xfrm_tmpl_resolve+0xa26/0xf10 net/xfrm/xfrm_policy.c:2541
  xfrm_resolve_and_create_bundle+0x140/0x2570 net/xfrm/xfrm_policy.c:2835
  xfrm_bundle_lookup net/xfrm/xfrm_policy.c:3070 [inline]
  xfrm_lookup_with_ifid+0x4d1/0x1e60 net/xfrm/xfrm_policy.c:3201
  xfrm_lookup net/xfrm/xfrm_policy.c:3298 [inline]
  xfrm_lookup_route+0x3b/0x200 net/xfrm/xfrm_policy.c:3309
  ip6_dst_lookup_flow+0x15c/0x1d0 net/ipv6/ip6_output.c:1256
  send6+0x611/0xd20 drivers/net/wireguard/socket.c:139
  wg_socket_send_skb_to_peer+0xf9/0x220 drivers/net/wireguard/socket.c:178
  wg_socket_send_buffer_to_peer+0x12b/0x190 drivers/net/wireguard/socket.c:200
  wg_packet_send_handshake_initiation+0x227/0x360 drivers/net/wireguard/send.c:40
  wg_packet_handshake_send_worker+0x1c/0x30 drivers/net/wireguard/send.c:51
  process_one_work+0x9fb/0x1b60 kernel/workqueue.c:3231
  process_scheduled_works kernel/workqueue.c:3312 [inline]
  worker_thread+0x6c8/0xf70 kernel/workqueue.c:3393
  kthread+0x2c1/0x3a0 kernel/kthread.c:389
  ret_from_fork+0x45/0x80 arch/x86/kernel/process.c:147
  ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
CVE-2024-41041:In the Linux kernel, the following vulnerability has been resolved:
udp: Set SOCK_RCU_FREE earlier in udp_lib_get_port().
syzkaller triggered the warning [0] in udp_v4_early_demux().
In udp_v[46]_early_demux() and sk_lookup(), we do not touch the refcount
of the looked-up sk and use sock_pfree() as skb-&gt;destructor, so we check
SOCK_RCU_FREE to ensure that the sk is safe to access during the RCU grace
period.
Currently, SOCK_RCU_FREE is flagged for a bound socket after being put
into the hash table.  Moreover, the SOCK_RCU_FREE check is done too early
in udp_v[46]_early_demux() and sk_lookup(), so there could be a small race
window:
  CPU1                                 CPU2
  ----                                 ----
  udp_v4_early_demux()                 udp_lib_get_port()
  |                                    |- hlist_add_head_rcu()
  |- sk = __udp4_lib_demux_lookup()    |
  |- DEBUG_NET_WARN_ON_ONCE(sk_is_refcounted(sk));
                                       `- sock_set_flag(sk, SOCK_RCU_FREE)
We had the same bug in TCP and fixed it in commit 871019b22d1b (&quot;net:
set SOCK_RCU_FREE before inserting socket into hashtable&quot;).
Let's apply the same fix for UDP.
[0]:
WARNING: CPU: 0 PID: 11198 at net/ipv4/udp.c:2599 udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
Modules linked in:
CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014
RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599
Code: c5 7a 15 fe bb 01 00 00 00 44 89 e9 31 ff d3 e3 81 e3 bf ef ff ff 89 de e8 2c 74 15 fe 85 db 0f 85 02 06 00 00 e8 9f 7a 15 fe &lt;0f&gt; 0b e8 98 7a 15 fe 49 8d 7e 60 e8 4f 39 2f fe 49 c7 46 60 20 52
RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293
RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92c
RDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001
RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000
R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680
R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004e
FS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ip_rcv_finish_core.constprop.0+0xbdd/0xd20 net/ipv4/ip_input.c:349
 ip_rcv_finish+0xda/0x150 net/ipv4/ip_input.c:447
 NF_HOOK include/linux/netfilter.h:314 [inline]
 NF_HOOK include/linux/netfilter.h:308 [inline]
 ip_rcv+0x16c/0x180 net/ipv4/ip_input.c:569
 __netif_receive_skb_one_core+0xb3/0xe0 net/core/dev.c:5624
 __netif_receive_skb+0x21/0xd0 net/core/dev.c:5738
 netif_receive_skb_internal net/core/dev.c:5824 [inline]
 netif_receive_skb+0x271/0x300 net/core/dev.c:5884
 tun_rx_batched drivers/net/tun.c:1549 [inline]
 tun_get_user+0x24db/0x2c50 drivers/net/tun.c:2002
 tun_chr_write_iter+0x107/0x1a0 drivers/net/tun.c:2048
 new_sync_write fs/read_write.c:497 [inline]
 vfs_write+0x76f/0x8d0 fs/read_write.c:590
 ksys_write+0xbf/0x190 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+0x41/0x50 fs/read_write.c:652
 x64_sys_call+0xe66/0x1990 arch/x86/include/generated/asm/syscalls_64.h:2
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0x4b/0x110 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x4b/0x53
RIP: 0033:0x7fc44a68bc1f
Code: 89 54 24 18 48 89 74 24 10 89 7c 24 08 e8 e9 cf f5 ff 48 8b 54 24 18 48 8b 74 24 10 41 89 c0 8b 7c 24 08 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 31 44 89 c7 48 89 44 24 08 e8 3c d0 f5 ff 48
RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001
RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1f
R
---truncated---
CVE-2024-41077:In the Linux kernel, the following vulnerability has been resolved:
null_blk: fix validation of block size
Block size should be between 512 and PAGE_SIZE and be a power of 2. The current
check does not validate this, so update the check.
Without this patch, null_blk would Oops due to a null pointer deref when
loaded with bs=1536 [1].
[axboe: remove unnecessary braces and != 0 check]
CVE-2024-41080:In the Linux kernel, the following vulnerability has been resolved:
io_uring: fix possible deadlock in io_register_iowq_max_workers()
The io_register_iowq_max_workers() function calls io_put_sq_data(),
which acquires the sqd-&gt;lock without releasing the uring_lock.
Similar to the commit 009ad9f0c6ee (&quot;io_uring: drop ctx-&gt;uring_lock
before acquiring sqd-&gt;lock&quot;), this can lead to a potential deadlock
situation.
To resolve this issue, the uring_lock is released before calling
io_put_sq_data(), and then it is re-acquired after the function call.
This change ensures that the locks are acquired in the correct
order, preventing the possibility of a deadlock.
CVE-2024-39471:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: add error handle to avoid out-of-bounds
if the sdma_v4_0_irq_id_to_seq return -EINVAL, the process should
be stop to avoid out-of-bounds read, so directly return -EINVAL.
CVE-2024-42115:In the Linux kernel, the following vulnerability has been resolved:
jffs2: Fix potential illegal address access in jffs2_free_inode
During the stress testing of the jffs2 file system,the following
abnormal printouts were found:
[ 2430.649000] Unable to handle kernel paging request at virtual address 0069696969696948
[ 2430.649622] Mem abort info:
[ 2430.649829]   ESR = 0x96000004
[ 2430.650115]   EC = 0x25: DABT (current EL), IL = 32 bits
[ 2430.650564]   SET = 0, FnV = 0
[ 2430.650795]   EA = 0, S1PTW = 0
[ 2430.651032]   FSC = 0x04: level 0 translation fault
[ 2430.651446] Data abort info:
[ 2430.651683]   ISV = 0, ISS = 0x00000004
[ 2430.652001]   CM = 0, WnR = 0
[ 2430.652558] [0069696969696948] address between user and kernel address ranges
[ 2430.653265] Internal error: Oops: 96000004 [#1] PREEMPT SMP
[ 2430.654512] CPU: 2 PID: 20919 Comm: cat Not tainted 5.15.25-g512f31242bf6 #33
[ 2430.655008] Hardware name: linux,dummy-virt (DT)
[ 2430.655517] pstate: 20000005 (nzCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[ 2430.656142] pc : kfree+0x78/0x348
[ 2430.656630] lr : jffs2_free_inode+0x24/0x48
[ 2430.657051] sp : ffff800009eebd10
[ 2430.657355] x29: ffff800009eebd10 x28: 0000000000000001 x27: 0000000000000000
[ 2430.658327] x26: ffff000038f09d80 x25: 0080000000000000 x24: ffff800009d38000
[ 2430.658919] x23: 5a5a5a5a5a5a5a5a x22: ffff000038f09d80 x21: ffff8000084f0d14
[ 2430.659434] x20: ffff0000bf9a6ac0 x19: 0169696969696940 x18: 0000000000000000
[ 2430.659969] x17: ffff8000b6506000 x16: ffff800009eec000 x15: 0000000000004000
[ 2430.660637] x14: 0000000000000000 x13: 00000001000820a1 x12: 00000000000d1b19
[ 2430.661345] x11: 0004000800000000 x10: 0000000000000001 x9 : ffff8000084f0d14
[ 2430.662025] x8 : ffff0000bf9a6b40 x7 : ffff0000bf9a6b48 x6 : 0000000003470302
[ 2430.662695] x5 : ffff00002e41dcc0 x4 : ffff0000bf9aa3b0 x3 : 0000000003470342
[ 2430.663486] x2 : 0000000000000000 x1 : ffff8000084f0d14 x0 : fffffc0000000000
[ 2430.664217] Call trace:
[ 2430.664528]  kfree+0x78/0x348
[ 2430.664855]  jffs2_free_inode+0x24/0x48
[ 2430.665233]  i_callback+0x24/0x50
[ 2430.665528]  rcu_do_batch+0x1ac/0x448
[ 2430.665892]  rcu_core+0x28c/0x3c8
[ 2430.666151]  rcu_core_si+0x18/0x28
[ 2430.666473]  __do_softirq+0x138/0x3cc
[ 2430.666781]  irq_exit+0xf0/0x110
[ 2430.667065]  handle_domain_irq+0x6c/0x98
[ 2430.667447]  gic_handle_irq+0xac/0xe8
[ 2430.667739]  call_on_irq_stack+0x28/0x54
The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field of
the jffs_inode_info structure. It was found that all variables in the jffs_inode_info
structure were 5a5a5a5a, except for the first member sem. It is suspected that these
variables are not initialized because they were set to 5a5a5a5a during memory testing,
which is meant to detect uninitialized memory.The sem variable is initialized in the
function jffs2_i_init_once, while other members are initialized in
the function jffs2_init_inode_info.
The function jffs2_init_inode_info is called after iget_locked,
but in the iget_locked function, the destroy_inode process is triggered,
which releases the inode and consequently, the target member of the inode
is not initialized.In concurrent high pressure scenarios, iget_locked
may enter the destroy_inode branch as described in the code.
Since the destroy_inode functionality of jffs2 only releases the target,
the fix method is to set target to NULL in jffs2_i_init_once.
CVE-2024-42097:In the Linux kernel, the following vulnerability has been resolved:
ALSA: emux: improve patch ioctl data validation
In load_data(), make the validation of and skipping over the main info
block match that in load_guspatch().
In load_guspatch(), add checking that the specified patch length matches
the actually supplied data, like load_data() already did.
CVE-2024-42086:In the Linux kernel, the following vulnerability has been resolved:
iio: chemical: bme680: Fix overflows in compensate() functions
There are cases in the compensate functions of the driver that
there could be overflows of variables due to bit shifting ops.
These implications were initially discussed here [1] and they
were mentioned in log message of Commit 1b3bd8592780 (&quot;iio:
chemical: Add support for Bosch BME680 sensor&quot;).
[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/
CVE-2024-42228:In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Using uninitialized value *size when calling amdgpu_vce_cs_relocInitialize the size before calling amdgpu_vce_cs_reloc, such as case 0x03000001.V2: To really improve the handling we would actually   need to have a separate value of 0xffffffff.(Christian)
CVE-2024-41014:In the Linux kernel, the following vulnerability has been resolved:
xfs: add bounds checking to xlog_recover_process_data
There is a lack of verification of the space occupied by fixed members
of xlog_op_header in the xlog_recover_process_data.
We can create a crafted image to trigger an out of bounds read by
following these steps:
    1) Mount an image of xfs, and do some file operations to leave records
    2) Before umounting, copy the image for subsequent steps to simulate
       abnormal exit. Because umount will ensure that tail_blk and
       head_blk are the same, which will result in the inability to enter
       xlog_recover_process_data
    3) Write a tool to parse and modify the copied image in step 2
    4) Make the end of the xlog_op_header entries only 1 byte away from
       xlog_rec_header-&gt;h_size
    5) xlog_rec_header-&gt;h_num_logops++
    6) Modify xlog_rec_header-&gt;h_crc
Fix:
Add a check to make sure there is sufficient space to access fixed members
of xlog_op_header.
CVE-2024-41063:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: hci_core: cancel all works upon hci_unregister_dev()
syzbot is reporting that calling hci_release_dev() from hci_error_reset()
due to hci_dev_put() from hci_error_reset() can cause deadlock at
destroy_workqueue(), for hci_error_reset() is called from
hdev-&gt;req_workqueue which destroy_workqueue() needs to flush.
We need to make sure that hdev-&gt;{rx_work,cmd_work,tx_work} which are
queued into hdev-&gt;workqueue and hdev-&gt;{power_on,error_reset} which are
queued into hdev-&gt;req_workqueue are no longer running by the moment
       destroy_workqueue(hdev-&gt;workqueue);
       destroy_workqueue(hdev-&gt;req_workqueue);
are called from hci_release_dev().
Call cancel_work_sync() on these work items from hci_unregister_dev()
as soon as hdev-&gt;list is removed from hci_dev_list.
CVE-2024-42084:In the Linux kernel, the following vulnerability has been resolved:
ftruncate: pass a signed offset
The old ftruncate() syscall, using the 32-bit off_t misses a sign
extension when called in compat mode on 64-bit architectures.  As a
result, passing a negative length accidentally succeeds in truncating
to file size between 2GiB and 4GiB.
Changing the type of the compat syscall to the signed compat_off_t
changes the behavior so it instead returns -EINVAL.
The native entry point, the truncate() syscall and the corresponding
loff_t based variants are all correct already and do not suffer
from this mistake.
CVE-2024-40961:In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent possible NULL deref in fib6_nh_init()
syzbot reminds us that in6_dev_get() can return NULL.
fib6_nh_init()
    ip6_validate_gw(  &amp;idev  )
        ip6_route_check_nh(  idev  )
            *idev = in6_dev_get(dev); // can be NULL
Oops: 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: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
 RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606
Code: 00 00 fc ff df 4c 8b 64 24 58 48 8b 44 24 28 4c 8b 74 24 30 48 89 c1 48 89 44 24 28 48 8d 98 e0 05 00 00 48 89 d8 48 c1 e8 03 &lt;42&gt; 0f b6 04 38 84 c0 0f 85 b3 17 00 00 8b 1b 31 ff 89 de e8 b8 8b
RSP: 0018:ffffc900032775a0 EFLAGS: 00010202
RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000
RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8
RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000
R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8
R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000
FS:  00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
Call Trace:
 &lt;TASK&gt;
  ip6_route_info_create+0x99e/0x12b0 net/ipv6/route.c:3809
  ip6_route_add+0x28/0x160 net/ipv6/route.c:3853
  ipv6_route_ioctl+0x588/0x870 net/ipv6/route.c:4483
  inet6_ioctl+0x21a/0x280 net/ipv6/af_inet6.c:579
  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:907 [inline]
  __se_sys_ioctl+0xfc/0x170 fs/ioctl.c:893
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f940f07cea9
CVE-2024-41090:In the Linux kernel, the following vulnerability has been resolved:
tap: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tap_get_user_xdp() path, which could cause a corrupted skb to be
sent downstack. Even before the skb is transmitted, the
tap_get_user_xdp()--&gt;skb_set_network_header() may assume the size is more
than ETH_HLEN. Once transmitted, this could either cause out-of-bound
access beyond the actual length, or confuse the underlayer with incorrect
or inconsistent header length in the skb metadata.
In the alternative path, tap_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted.
This is to drop any frame shorter than the Ethernet header size just like
how tap_get_user() does.
CVE: CVE-2024-41090
CVE-2024-41091:In the Linux kernel, the following vulnerability has been resolved:
tun: add missing verification for short frame
The cited commit missed to check against the validity of the frame length
in the tun_xdp_one() path, which could cause a corrupted skb to be sent
downstack. Even before the skb is transmitted, the
tun_xdp_one--&gt;eth_type_trans() may access the Ethernet header although it
can be less than ETH_HLEN. Once transmitted, this could either cause
out-of-bound access beyond the actual length, or confuse the underlayer
with incorrect or inconsistent header length in the skb metadata.
In the alternative path, tun_get_user() already prohibits short frame which
has the length less than Ethernet header size from being transmitted for
IFF_TAP.
This is to drop any frame shorter than the Ethernet header size just like
how tun_get_user() does.
CVE: CVE-2024-41091
CVE-2024-41020:In the Linux kernel, the following vulnerability has been resolved:
filelock: Fix fcntl/close race recovery compat path
When I wrote commit 3cad1bc01041 (&quot;filelock: Remove locks reliably when
fcntl/close race is detected&quot;), I missed that there are two copies of the
code I was patching: The normal version, and the version for 64-bit offsets
on 32-bit kernels.
Thanks to Greg KH for stumbling over this while doing the stable
backport...
Apply exactly the same fix to the compat path for 32-bit kernels.
CVE-2024-42068:In the Linux kernel, the following vulnerability has been resolved:
bpf: Take return from set_memory_ro() into account with bpf_prog_lock_ro()
set_memory_ro() can fail, leaving memory unprotected.
Check its return and take it into account as an error.
CVE-2024-41048:In the Linux kernel, the following vulnerability has been resolved:
skmsg: Skip zero length skb in sk_msg_recvmsg
When running BPF selftests (./test_progs -t sockmap_basic) on a Loongarch
platform, the following kernel panic occurs:
  [...]
  Oops[#1]:
  CPU: 22 PID: 2824 Comm: test_progs Tainted: G           OE  6.10.0-rc2+ #18
  Hardware name: LOONGSON Dabieshan/Loongson-TC542F0, BIOS Loongson-UDK2018
     ... ...
     ra: 90000000048bf6c0 sk_msg_recvmsg+0x120/0x560
    ERA: 9000000004162774 copy_page_to_iter+0x74/0x1c0
   CRMD: 000000b0 (PLV0 -IE -DA +PG DACF=CC DACM=CC -WE)
   PRMD: 0000000c (PPLV0 +PIE +PWE)
   EUEN: 00000007 (+FPE +SXE +ASXE -BTE)
   ECFG: 00071c1d (LIE=0,2-4,10-12 VS=7)
  ESTAT: 00010000 [PIL] (IS= ECode=1 EsubCode=0)
   BADV: 0000000000000040
   PRID: 0014c011 (Loongson-64bit, Loongson-3C5000)
  Modules linked in: bpf_testmod(OE) xt_CHECKSUM xt_MASQUERADE xt_conntrack
  Process test_progs (pid: 2824, threadinfo=0000000000863a31, task=...)
  Stack : ...
  Call Trace:
  [&lt;9000000004162774&gt;] copy_page_to_iter+0x74/0x1c0
  [&lt;90000000048bf6c0&gt;] sk_msg_recvmsg+0x120/0x560
  [&lt;90000000049f2b90&gt;] tcp_bpf_recvmsg_parser+0x170/0x4e0
  [&lt;90000000049aae34&gt;] inet_recvmsg+0x54/0x100
  [&lt;900000000481ad5c&gt;] sock_recvmsg+0x7c/0xe0
  [&lt;900000000481e1a8&gt;] __sys_recvfrom+0x108/0x1c0
  [&lt;900000000481e27c&gt;] sys_recvfrom+0x1c/0x40
  [&lt;9000000004c076ec&gt;] do_syscall+0x8c/0xc0
  [&lt;9000000003731da4&gt;] handle_syscall+0xc4/0x160
  Code: ...
  ---[ end trace 0000000000000000 ]---
  Kernel panic - not syncing: Fatal exception
  Kernel relocated by 0x3510000
   .text @ 0x9000000003710000
   .data @ 0x9000000004d70000
   .bss  @ 0x9000000006469400
  ---[ end Kernel panic - not syncing: Fatal exception ]---
  [...]
This crash happens every time when running sockmap_skb_verdict_shutdown
subtest in sockmap_basic.
This crash is because a NULL pointer is passed to page_address() in the
sk_msg_recvmsg(). Due to the different implementations depending on the
architecture, page_address(NULL) will trigger a panic on Loongarch
platform but not on x86 platform. So this bug was hidden on x86 platform
for a while, but now it is exposed on Loongarch platform. The root cause
is that a zero length skb (skb-&gt;len == 0) was put on the queue.
This zero length skb is a TCP FIN packet, which was sent by shutdown(),
invoked in test_sockmap_skb_verdict_shutdown():
	shutdown(p1, SHUT_WR);
In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and no
page is put to this sge (see sg_set_page in sg_set_page), but this empty
sge is queued into ingress_msg list.
And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got by
sg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes it
to kmap_local_page() and to page_address(), then kernel panics.
To solve this, we should skip this zero length skb. So in sk_msg_recvmsg(),
if copy is zero, that means it's a zero length skb, skip invoking
copy_page_to_iter(). We are using the EFAULT return triggered by
copy_page_to_iter to check for is_fin in tcp_bpf.c.
CVE-2023-52887:In the Linux kernel, the following vulnerability has been resolved:
net: can: j1939: enhanced error handling for tightly received RTS messages in xtp_rx_rts_session_new
This patch enhances error handling in scenarios with RTS (Request to
Send) messages arriving closely. It replaces the less informative WARN_ON_ONCE
backtraces with a new error handling method. This provides clearer error
messages and allows for the early termination of problematic sessions.
Previously, sessions were only released at the end of j1939_xtp_rx_rts().
Potentially this could be reproduced with something like:
testj1939 -r vcan0:0x80 &amp;
while true; do
	# send first RTS
	cansend vcan0 18EC8090#1014000303002301;
	# send second RTS
	cansend vcan0 18EC8090#1014000303002301;
	# send abort
	cansend vcan0 18EC8090#ff00000000002301;
done
CVE-2024-42092:In the Linux kernel, the following vulnerability has been resolved:
gpio: davinci: Validate the obtained number of IRQs
Value of pdata-&gt;gpio_unbanked is taken from Device Tree. In case of broken
DT due to any error this value can be any. Without this value validation
there can be out of chips-&gt;irqs array boundaries access in
davinci_gpio_probe().
Validate the obtained nirq value so that it won't exceed the maximum
number of IRQs per bank.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-41081:In the Linux kernel, the following vulnerability has been resolved:
ila: block BH in ila_output()
As explained in commit 1378817486d6 (&quot;tipc: block BH
before using dst_cache&quot;), net/core/dst_cache.c
helpers need to be called with BH disabled.
ila_output() is called from lwtunnel_output()
possibly from process context, and under rcu_read_lock().
We might be interrupted by a softirq, re-enter ila_output()
and corrupt dst_cache data structures.
Fix the race by using local_bh_disable().
CVE-2024-42161:In the Linux kernel, the following vulnerability has been resolved:bpf: Avoid uninitialized value in BPF_CORE_READ_BITFIELD[Changes from V1: - Use a default branch in the switch statement to initialize `val .]GCC warns that `val  may be used uninitialized in theBPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as: [...] unsigned long long val;              [...]                switch (__CORE_RELO(s, field, BYTE_SIZE)) {           case 1: val = *(const unsigned char *)p; break;           case 2: val = *(const unsigned short *)p; break;          case 4: val = *(const unsigned int *)p; break;           case 8: val = *(const unsigned long long *)p; break;                 }                      [...] val;                }               This patch adds a default entry in the switch statement that sets`val  to zero in order to avoid the warning, and random values to beused in case __builtin_preserve_field_info returns unexpected valuesfor BPF_FIELD_BYTE_SIZE.Tested in bpf-next master.No regressions.
CVE-2024-40910:In the Linux kernel, the following vulnerability has been resolved:
ax25: Fix refcount imbalance on inbound connections
When releasing a socket in ax25_release(), we call netdev_put() to
decrease the refcount on the associated ax.25 device. However, the
execution path for accepting an incoming connection never calls
netdev_hold(). This imbalance leads to refcount errors, and ultimately
to kernel crashes.
A typical call trace for the above situation will start with one of the
following errors:
    refcount_t: decrement hit 0; leaking memory.
    refcount_t: underflow; use-after-free.
And will then have a trace like:
    Call Trace:
    &lt;TASK&gt;
    ? show_regs+0x64/0x70
    ? __warn+0x83/0x120
    ? refcount_warn_saturate+0xb2/0x100
    ? report_bug+0x158/0x190
    ? prb_read_valid+0x20/0x30
    ? handle_bug+0x3e/0x70
    ? exc_invalid_op+0x1c/0x70
    ? asm_exc_invalid_op+0x1f/0x30
    ? refcount_warn_saturate+0xb2/0x100
    ? refcount_warn_saturate+0xb2/0x100
    ax25_release+0x2ad/0x360
    __sock_release+0x35/0xa0
    sock_close+0x19/0x20
    [...]
On reboot (or any attempt to remove the interface), the kernel gets
stuck in an infinite loop:
    unregister_netdevice: waiting for ax0 to become free. Usage count = 0
This patch corrects these issues by ensuring that we call netdev_hold()
and ax25_dev_hold() for new connections in ax25_accept(). This makes the
logic leading to ax25_accept() match the logic for ax25_bind(): in both
cases we increment the refcount, which is ultimately decremented in
ax25_release().
CVE-2024-41046:In the Linux kernel, the following vulnerability has been resolved:
net: ethernet: lantiq_etop: fix double free in detach
The number of the currently released descriptor is never incremented
which results in the same skb being released multiple times.
CVE-2024-41044:In the Linux kernel, the following vulnerability has been resolved:
ppp: reject claimed-as-LCP but actually malformed packets
Since 'ppp_async_encode()' assumes valid LCP packets (with code
from 1 to 7 inclusive), add 'ppp_check_packet()' to ensure that
LCP packet has an actual body beyond PPP_LCP header bytes, and
reject claimed-as-LCP but actually malformed data otherwise.
CVE-2024-42145:In the Linux kernel, the following vulnerability has been resolved:
IB/core: Implement a limit on UMAD receive List
The existing behavior of ib_umad, which maintains received MAD
packets in an unbounded list, poses a risk of uncontrolled growth.
As user-space applications extract packets from this list, the rate
of extraction may not match the rate of incoming packets, leading
to potential list overflow.
To address this, we introduce a limit to the size of the list. After
considering typical scenarios, such as OpenSM processing, which can
handle approximately 100k packets per second, and the 1-second retry
timeout for most packets, we set the list size limit to 200k. Packets
received beyond this limit are dropped, assuming they are likely timed
out by the time they are handled by user-space.
Notably, packets queued on the receive list due to reasons like
timed-out sends are preserved even when the list is full.
CVE-2024-41072:In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: wext: add extra SIOCSIWSCAN data check
In 'cfg80211_wext_siwscan()', add extra check whether number of
channels passed via 'ioctl(sock, SIOCSIWSCAN, ...)' doesn't exceed
IW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.
CVE-2024-41035:In the Linux kernel, the following vulnerability has been resolved:
USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptor
Syzbot has identified a bug in usbcore (see the Closes: tag below)
caused by our assumption that the reserved bits in an endpoint
descriptor's bEndpointAddress field will always be 0.  As a result of
the bug, the endpoint_is_duplicate() routine in config.c (and possibly
other routines as well) may believe that two descriptors are for
distinct endpoints, even though they have the same direction and
endpoint number.  This can lead to confusion, including the bug
identified by syzbot (two descriptors with matching endpoint numbers
and directions, where one was interrupt and the other was bulk).
To fix the bug, we will clear the reserved bits in bEndpointAddress
when we parse the descriptor.  (Note that both the USB-2.0 and USB-3.1
specs say these bits are &quot;Reserved, reset to zero&quot;.)  This requires us
to make a copy of the descriptor earlier in usb_parse_endpoint() and
use the copy instead of the original when checking for duplicates.
CVE-2024-42155:In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe copies of protected- and secure-keys
Although the clear-key of neither protected- nor secure-keys is
accessible, this key material should only be visible to the calling
process. So wipe all copies of protected- or secure-keys from stack,
even in case of an error.
CVE-2024-42129:In the Linux kernel, the following vulnerability has been resolved:
leds: mlxreg: Use devm_mutex_init() for mutex initialization
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
CVE-2024-41023:In the Linux kernel, the following vulnerability has been resolved:
sched/deadline: Fix task_struct reference leak
During the execution of the following stress test with linux-rt:
stress-ng --cyclic 30 --timeout 30 --minimize --quiet
kmemleak frequently reported a memory leak concerning the task_struct:
unreferenced object 0xffff8881305b8000 (size 16136):
  comm &quot;stress-ng&quot;, pid 614, jiffies 4294883961 (age 286.412s)
  object hex dump (first 32 bytes):
    02 40 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  ................
  debug hex dump (first 16 bytes):
    53 09 00 00 00 00 00 00 00 00 00 00 00 00 00 00  S...............
  backtrace:
    [&lt;00000000046b6790&gt;] dup_task_struct+0x30/0x540
    [&lt;00000000c5ca0f0b&gt;] copy_process+0x3d9/0x50e0
    [&lt;00000000ced59777&gt;] kernel_clone+0xb0/0x770
    [&lt;00000000a50befdc&gt;] __do_sys_clone+0xb6/0xf0
    [&lt;000000001dbf2008&gt;] do_syscall_64+0x5d/0xf0
    [&lt;00000000552900ff&gt;] entry_SYSCALL_64_after_hwframe+0x6e/0x76
The issue occurs in start_dl_timer(), which increments the task_struct
reference count and sets a timer. The timer callback, dl_task_timer,
is supposed to decrement the reference count upon expiration. However,
if enqueue_task_dl() is called before the timer expires and cancels it,
the reference count is not decremented, leading to the leak.
This patch fixes the reference leak by ensuring the task_struct
reference count is properly decremented when the timer is canceled.
CVE-2024-42080:In the Linux kernel, the following vulnerability has been resolved:
RDMA/restrack: Fix potential invalid address access
struct rdma_restrack_entry's kern_name was set to KBUILD_MODNAME
in ib_create_cq(), while if the module exited but forgot del this
rdma_restrack_entry, it would cause a invalid address access in
rdma_restrack_clean() when print the owner of this rdma_restrack_entry.
These code is used to help find one forgotten PD release in one of the
ULPs. But it is not needed anymore, so delete them.
CVE-2024-41097:In the Linux kernel, the following vulnerability has been resolved:
usb: atm: cxacru: fix endpoint checking in cxacru_bind()
Syzbot is still reporting quite an old issue [1] that occurs due to
incomplete checking of present usb endpoints. As such, wrong
endpoints types may be used at urb sumbitting stage which in turn
triggers a warning in usb_submit_urb().
Fix the issue by verifying that required endpoint types are present
for both in and out endpoints, taking into account cmd endpoint type.
Unfortunately, this patch has not been tested on real hardware.
[1] Syzbot report:
usb 1-1: BOGUS urb xfer, pipe 1 != type 3
WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
Modules linked in:
CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
RIP: 0010:usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502
...
Call Trace:
 cxacru_cm+0x3c0/0x8e0 drivers/usb/atm/cxacru.c:649
 cxacru_card_status+0x22/0xd0 drivers/usb/atm/cxacru.c:760
 cxacru_bind+0x7ac/0x11a0 drivers/usb/atm/cxacru.c:1209
 usbatm_usb_probe+0x321/0x1ae0 drivers/usb/atm/usbatm.c:1055
 cxacru_usb_probe+0xdf/0x1e0 drivers/usb/atm/cxacru.c:1363
 usb_probe_interface+0x315/0x7f0 drivers/usb/core/driver.c:396
 call_driver_probe drivers/base/dd.c:517 [inline]
 really_probe+0x23c/0xcd0 drivers/base/dd.c:595
 __driver_probe_device+0x338/0x4d0 drivers/base/dd.c:747
 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:777
 __device_attach_driver+0x20b/0x2f0 drivers/base/dd.c:894
 bus_for_each_drv+0x15f/0x1e0 drivers/base/bus.c:427
 __device_attach+0x228/0x4a0 drivers/base/dd.c:965
 bus_probe_device+0x1e4/0x290 drivers/base/bus.c:487
 device_add+0xc2f/0x2180 drivers/base/core.c:3354
 usb_set_configuration+0x113a/0x1910 drivers/usb/core/message.c:2170
 usb_generic_driver_probe+0xba/0x100 drivers/usb/core/generic.c:238
 usb_probe_device+0xd9/0x2c0 drivers/usb/core/driver.c:293
CVE-2024-42106:In the Linux kernel, the following vulnerability has been resolved:
inet_diag: Initialize pad field in struct inet_diag_req_v2
KMSAN reported uninit-value access in raw_lookup() [1]. Diag for raw
sockets uses the pad field in struct inet_diag_req_v2 for the
underlying protocol. This field corresponds to the sdiag_raw_protocol
field in struct inet_diag_req_raw.
inet_diag_get_exact_compat() converts inet_diag_req to
inet_diag_req_v2, but leaves the pad field uninitialized. So the issue
occurs when raw_lookup() accesses the sdiag_raw_protocol field.
Fix this by initializing the pad field in
inet_diag_get_exact_compat(). Also, do the same fix in
inet_diag_dump_compat() to avoid the similar issue in the future.
[1]
BUG: KMSAN: uninit-value in raw_lookup net/ipv4/raw_diag.c:49 [inline]
BUG: KMSAN: uninit-value in raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
 raw_lookup net/ipv4/raw_diag.c:49 [inline]
 raw_sock_get+0x657/0x800 net/ipv4/raw_diag.c:71
 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
 inet_diag_cmd_exact+0x7d9/0x980
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
 inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
 netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x332/0x3d0 net/socket.c:745
 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
 __sys_sendmsg net/socket.c:2668 [inline]
 __do_sys_sendmsg net/socket.c:2677 [inline]
 __se_sys_sendmsg net/socket.c:2675 [inline]
 __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was stored to memory at:
 raw_sock_get+0x650/0x800 net/ipv4/raw_diag.c:71
 raw_diag_dump_one+0xa1/0x660 net/ipv4/raw_diag.c:99
 inet_diag_cmd_exact+0x7d9/0x980
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1404 [inline]
 inet_diag_rcv_msg_compat+0x469/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
 netlink_rcv_skb+0x537/0x670 net/netlink/af_netlink.c:2564
 sock_diag_rcv+0x35/0x40 net/core/sock_diag.c:297
 netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]
 netlink_unicast+0xe74/0x1240 net/netlink/af_netlink.c:1361
 netlink_sendmsg+0x10c6/0x1260 net/netlink/af_netlink.c:1905
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x332/0x3d0 net/socket.c:745
 ____sys_sendmsg+0x7f0/0xb70 net/socket.c:2585
 ___sys_sendmsg+0x271/0x3b0 net/socket.c:2639
 __sys_sendmsg net/socket.c:2668 [inline]
 __do_sys_sendmsg net/socket.c:2677 [inline]
 __se_sys_sendmsg net/socket.c:2675 [inline]
 __x64_sys_sendmsg+0x27e/0x4a0 net/socket.c:2675
 x64_sys_call+0x135e/0x3ce0 arch/x86/include/generated/asm/syscalls_64.h:47
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xd9/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Local variable req.i created at:
 inet_diag_get_exact_compat net/ipv4/inet_diag.c:1396 [inline]
 inet_diag_rcv_msg_compat+0x2a6/0x530 net/ipv4/inet_diag.c:1426
 sock_diag_rcv_msg+0x23d/0x740 net/core/sock_diag.c:282
CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
CVE-2024-42224:In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Correct check for empty listSince commit a3c53be55c95 ( net: dsa: mv88e6xxx: Support multiple MDIObusses ) mv88e6xxx_default_mdio_bus() has checked that thereturn value of list_first_entry() is non-NULL.This appears to be intended to guard against the list chip-&gt;mdios beingempty.  However, it is not the correct check as the implementation oflist_first_entry is not designed to return NULL for empty lists.Instead, use list_first_entry_or_null() which does return NULL if thelist is empty.Flagged by Smatch.Compile tested only.
CVE-2024-41013:In the Linux kernel, the following vulnerability has been resolved:
xfs: don't walk off the end of a directory data block
This adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entry
to make sure don't stray beyond valid memory region. Before patching, the
loop simply checks that the start offset of the dup and dep is within the
range. So in a crafted image, if last entry is xfs_dir2_data_unused, we
can change dup-&gt;length to dup-&gt;length-1 and leave 1 byte of space. In the
next traversal, this space will be considered as dup or dep. We may
encounter an out of bound read when accessing the fixed members.
In the patch, we make sure that the remaining bytes large enough to hold
an unused entry before accessing xfs_dir2_data_unused and
xfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also make
sure that the remaining bytes large enough to hold a dirent with a
single-byte name before accessing xfs_dir2_data_entry.
CVE-2024-41070:In the Linux kernel, the following vulnerability has been resolved:
KVM: PPC: Book3S HV: Prevent UAF in kvm_spapr_tce_attach_iommu_group()
Al reported a possible use-after-free (UAF) in kvm_spapr_tce_attach_iommu_group().
It looks up `stt` from tablefd, but then continues to use it after doing
fdput() on the returned fd. After the fdput() the tablefd is free to be
closed by another thread. The close calls kvm_spapr_tce_release() and
then release_spapr_tce_table() (via call_rcu()) which frees `stt`.
Although there are calls to rcu_read_lock() in
kvm_spapr_tce_attach_iommu_group() they are not sufficient to prevent
the UAF, because `stt` is used outside the locked regions.
With an artifcial delay after the fdput() and a userspace program which
triggers the race, KASAN detects the UAF:
  BUG: KASAN: slab-use-after-free in kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
  Read of size 4 at addr c000200027552c30 by task kvm-vfio/2505
  CPU: 54 PID: 2505 Comm: kvm-vfio Not tainted 6.10.0-rc3-next-20240612-dirty #1
  Hardware name: 8335-GTH POWER9 0x4e1202 opal:skiboot-v6.5.3-35-g1851b2a06 PowerNV
  Call Trace:
    dump_stack_lvl+0xb4/0x108 (unreliable)
    print_report+0x2b4/0x6ec
    kasan_report+0x118/0x2b0
    __asan_load4+0xb8/0xd0
    kvm_spapr_tce_attach_iommu_group+0x298/0x720 [kvm]
    kvm_vfio_set_attr+0x524/0xac0 [kvm]
    kvm_device_ioctl+0x144/0x240 [kvm]
    sys_ioctl+0x62c/0x1810
    system_call_exception+0x190/0x440
    system_call_vectored_common+0x15c/0x2ec
  ...
  Freed by task 0:
   ...
   kfree+0xec/0x3e0
   release_spapr_tce_table+0xd4/0x11c [kvm]
   rcu_core+0x568/0x16a0
   handle_softirqs+0x23c/0x920
   do_softirq_own_stack+0x6c/0x90
   do_softirq_own_stack+0x58/0x90
   __irq_exit_rcu+0x218/0x2d0
   irq_exit+0x30/0x80
   arch_local_irq_restore+0x128/0x230
   arch_local_irq_enable+0x1c/0x30
   cpuidle_enter_state+0x134/0x5cc
   cpuidle_enter+0x6c/0xb0
   call_cpuidle+0x7c/0x100
   do_idle+0x394/0x410
   cpu_startup_entry+0x60/0x70
   start_secondary+0x3fc/0x410
   start_secondary_prolog+0x10/0x14
Fix it by delaying the fdput() until `stt` is no longer in use, which
is effectively the entire function. To keep the patch minimal add a call
to fdput() at each of the existing return paths. Future work can convert
the function to goto or __cleanup style cleanup.
With the fix in place the test case no longer triggers the UAF.
CVE-2024-41062:In the Linux kernel, the following vulnerability has been resolved:
bluetooth/l2cap: sync sock recv cb and release
The problem occurs between the system call to close the sock and hci_rx_work,
where the former releases the sock and the latter accesses it without lock protection.
           CPU0                       CPU1
           ----                       ----
           sock_close                 hci_rx_work
	   l2cap_sock_release         hci_acldata_packet
	   l2cap_sock_kill            l2cap_recv_frame
	   sk_free                    l2cap_conless_channel
	                              l2cap_sock_recv_cb
If hci_rx_work processes the data that needs to be received before the sock is
closed, then everything is normal; Otherwise, the work thread may access the
released sock when receiving data.
Add a chan mutex in the rx callback of the sock to achieve synchronization between
the sock release and recv cb.
Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.
CVE-2024-42089:In the Linux kernel, the following vulnerability has been resolved:
ASoC: fsl-asoc-card: set priv-&gt;pdev before using it
priv-&gt;pdev pointer was set after being used in
fsl_asoc_card_audmux_init().
Move this assignment at the start of the probe function, so
sub-functions can correctly use pdev through priv.
fsl_asoc_card_audmux_init() dereferences priv-&gt;pdev to get access to the
dev struct, used with dev_err macros.
As priv is zero-initialised, there would be a NULL pointer dereference.
Note that if priv-&gt;dev is dereferenced before assignment but never used,
for example if there is no error to be printed, the driver won't crash
probably due to compiler optimisations.
CVE-2024-42076:In the Linux kernel, the following vulnerability has been resolved:
net: can: j1939: Initialize unused data in j1939_send_one()
syzbot reported kernel-infoleak in raw_recvmsg() [1]. j1939_send_one()
creates full frame including unused data, but it doesn't initialize
it. This causes the kernel-infoleak issue. Fix this by initializing
unused data.
[1]
BUG: KMSAN: kernel-infoleak in instrument_copy_to_user include/linux/instrumented.h:114 [inline]
BUG: KMSAN: kernel-infoleak in copy_to_user_iter lib/iov_iter.c:24 [inline]
BUG: KMSAN: kernel-infoleak in iterate_ubuf include/linux/iov_iter.h:29 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance2 include/linux/iov_iter.h:245 [inline]
BUG: KMSAN: kernel-infoleak in iterate_and_advance include/linux/iov_iter.h:271 [inline]
BUG: KMSAN: kernel-infoleak in _copy_to_iter+0x366/0x2520 lib/iov_iter.c:185
 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+0x366/0x2520 lib/iov_iter.c:185
 copy_to_iter include/linux/uio.h:196 [inline]
 memcpy_to_msg include/linux/skbuff.h:4113 [inline]
 raw_recvmsg+0x2b8/0x9e0 net/can/raw.c:1008
 sock_recvmsg_nosec net/socket.c:1046 [inline]
 sock_recvmsg+0x2c4/0x340 net/socket.c:1068
 ____sys_recvmsg+0x18a/0x620 net/socket.c:2803
 ___sys_recvmsg+0x223/0x840 net/socket.c:2845
 do_recvmmsg+0x4fc/0xfd0 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+0x397/0x490 net/socket.c:3034
 x64_sys_call+0xf6c/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:300
 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:
 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:1313 [inline]
 alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6504
 sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2795
 sock_alloc_send_skb include/net/sock.h:1842 [inline]
 j1939_sk_alloc_skb net/can/j1939/socket.c:878 [inline]
 j1939_sk_send_loop net/can/j1939/socket.c:1142 [inline]
 j1939_sk_sendmsg+0xc0a/0x2730 net/can/j1939/socket.c:1277
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg+0x30f/0x380 net/socket.c:745
 ____sys_sendmsg+0x877/0xb60 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/0x4a0 net/socket.c:2674
 x64_sys_call+0xc4b/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:47
 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 12-15 of 16 are uninitialized
Memory access of size 16 starts at ffff888120969690
Data copied to user address 00000000200017c0
CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
CVE-2024-41089:In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modes
In nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().
Add a check to avoid null pointer dereference.
CVE-2024-42098:In the Linux kernel, the following vulnerability has been resolved:
crypto: ecdh - explicitly zeroize private_key
private_key is overwritten with the key parameter passed in by the
caller (if present), or alternatively a newly generated private key.
However, it is possible that the caller provides a key (or the newly
generated key) which is shorter than the previous key. In that
scenario, some key material from the previous key would not be
overwritten. The easiest solution is to explicitly zeroize the entire
private_key array first.
Note that this patch slightly changes the behavior of this function:
previously, if the ecc_gen_privkey failed, the old private_key would
remain. Now, the private_key is always zeroized. This behavior is
consistent with the case where params.key is set and ecc_is_key_valid
fails.
CVE-2024-42077:In the Linux kernel, the following vulnerability has been resolved:
ocfs2: fix DIO failure due to insufficient transaction credits
The code in ocfs2_dio_end_io_write() estimates number of necessary
transaction credits using ocfs2_calc_extend_credits().  This however does
not take into account that the IO could be arbitrarily large and can
contain arbitrary number of extents.
Extent tree manipulations do often extend the current transaction but not
in all of the cases.  For example if we have only single block extents in
the tree, ocfs2_mark_extent_written() will end up calling
ocfs2_replace_extent_rec() all the time and we will never extend the
current transaction and eventually exhaust all the transaction credits if
the IO contains many single block extents.  Once that happens a
WARN_ON(jbd2_handle_buffer_credits(handle) &lt;= 0) is triggered in
jbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response to
this error.  This was actually triggered by one of our customers on a
heavily fragmented OCFS2 filesystem.
To fix the issue make sure the transaction always has enough credits for
one extent insert before each call of ocfs2_mark_extent_written().
Heming Zhao said:
------
PANIC: &quot;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error&quot;
PID: xxx  TASK: xxxx  CPU: 5  COMMAND: &quot;SubmitThread-CA&quot;
  #0 machine_kexec at ffffffff8c069932
  #1 __crash_kexec at ffffffff8c1338fa
  #2 panic at ffffffff8c1d69b9
  #3 ocfs2_handle_error at ffffffffc0c86c0c [ocfs2]
  #4 __ocfs2_abort at ffffffffc0c88387 [ocfs2]
  #5 ocfs2_journal_dirty at ffffffffc0c51e98 [ocfs2]
  #6 ocfs2_split_extent at ffffffffc0c27ea3 [ocfs2]
  #7 ocfs2_change_extent_flag at ffffffffc0c28053 [ocfs2]
  #8 ocfs2_mark_extent_written at ffffffffc0c28347 [ocfs2]
  #9 ocfs2_dio_end_io_write at ffffffffc0c2bef9 [ocfs2]
#10 ocfs2_dio_end_io at ffffffffc0c2c0f5 [ocfs2]
#11 dio_complete at ffffffff8c2b9fa7
#12 do_blockdev_direct_IO at ffffffff8c2bc09f
#13 ocfs2_direct_IO at ffffffffc0c2b653 [ocfs2]
#14 generic_file_direct_write at ffffffff8c1dcf14
#15 __generic_file_write_iter at ffffffff8c1dd07b
#16 ocfs2_file_write_iter at ffffffffc0c49f1f [ocfs2]
#17 aio_write at ffffffff8c2cc72e
#18 kmem_cache_alloc at ffffffff8c248dde
#19 do_io_submit at ffffffff8c2ccada
#20 do_syscall_64 at ffffffff8c004984
#21 entry_SYSCALL_64_after_hwframe at ffffffff8c8000ba
CVE-2024-39497:In the Linux kernel, the following vulnerability has been resolved:
drm/shmem-helper: Fix BUG_ON() on mmap(PROT_WRITE, MAP_PRIVATE)
Lack of check for copy-on-write (COW) mapping in drm_gem_shmem_mmap
allows users to call mmap with PROT_WRITE and MAP_PRIVATE flag
causing a kernel panic due to BUG_ON in vmf_insert_pfn_prot:
BUG_ON((vma-&gt;vm_flags &amp; VM_PFNMAP) &amp;&amp; is_cow_mapping(vma-&gt;vm_flags));
Return -EINVAL early if COW mapping is detected.
This bug affects all drm drivers using default shmem helpers.
It can be reproduced by this simple example:
void *ptr = mmap(0, size, PROT_WRITE, MAP_PRIVATE, fd, mmap_offset);
ptr[0] = 0;
CVE-2024-42096:In the Linux kernel, the following vulnerability has been resolved:
x86: stop playing stack games in profile_pc()
The 'profile_pc()' function is used for timer-based profiling, which
isn't really all that relevant any more to begin with, but it also ends
up making assumptions based on the stack layout that aren't necessarily
valid.
Basically, the code tries to account the time spent in spinlocks to the
caller rather than the spinlock, and while I support that as a concept,
it's not worth the code complexity or the KASAN warnings when no serious
profiling is done using timers anyway these days.
And the code really does depend on stack layout that is only true in the
simplest of cases.  We've lost the comment at some point (I think when
the 32-bit and 64-bit code was unified), but it used to say:
	Assume the lock function has either no stack frame or a copy
	of eflags from PUSHF.
which explains why it just blindly loads a word or two straight off the
stack pointer and then takes a minimal look at the values to just check
if they might be eflags or the return pc:
	Eflags always has bits 22 and up cleared unlike kernel addresses
but that basic stack layout assumption assumes that there isn't any lock
debugging etc going on that would complicate the code and cause a stack
frame.
It causes KASAN unhappiness reported for years by syzkaller [1] and
others [2].
With no real practical reason for this any more, just remove the code.
Just for historical interest, here's some background commits relating to
this code from 2006:
  0cb91a229364 (&quot;i386: Account spinlocks to the caller during profiling for !FP kernels&quot;)
  31679f38d886 (&quot;Simplify profile_pc on x86-64&quot;)
and a code unification from 2009:
  ef4512882dbe (&quot;x86: time_32/64.c unify profile_pc&quot;)
but the basics of this thing actually goes back to before the git tree.
CVE-2024-41079:In the Linux kernel, the following vulnerability has been resolved:
nvmet: always initialize cqe.result
The spec doesn't mandate that the first two double words (aka results)
for the command queue entry need to be set to 0 when they are not
used (not specified). Though, the target implemention returns 0 for TCP
and FC but not for RDMA.
Let's make RDMA behave the same and thus explicitly initializing the
result field. This prevents leaking any data from the stack.
CVE-2024-42101:In the Linux kernel, the following vulnerability has been resolved:
drm/nouveau: fix null pointer dereference in nouveau_connector_get_modes
In nouveau_connector_get_modes(), the return value of drm_mode_duplicate()
is assigned to mode, which will lead to a possible NULL pointer
dereference on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2024-42162:In the Linux kernel, the following vulnerability has been resolved:
gve: Account for stopped queues when reading NIC stats
We now account for the fact that the NIC might send us stats for a
subset of queues. Without this change, gve_get_ethtool_stats might make
an invalid access on the priv-&gt;stats_report-&gt;stats array.
CVE-2024-42124:In the Linux kernel, the following vulnerability has been resolved:
scsi: qedf: Make qedf_execute_tmf() non-preemptible
Stop calling smp_processor_id() from preemptible code in
qedf_execute_tmf90.  This results in BUG_ON() when running an RT kernel.
[ 659.343280] BUG: using smp_processor_id() in preemptible [00000000] code: sg_reset/3646
[ 659.343282] caller is qedf_execute_tmf+0x8b/0x360 [qedf]
CVE-2024-42094:In the Linux kernel, the following vulnerability has been resolved:
net/iucv: Avoid explicit cpumask var allocation on stack
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config-neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
CVE-2024-41012:In the Linux kernel, the following vulnerability has been resolved:
filelock: Remove locks reliably when fcntl/close race is detected
When fcntl_setlk() races with close(), it removes the created lock with
do_lock_file_wait().
However, LSMs can allow the first do_lock_file_wait() that created the lock
while denying the second do_lock_file_wait() that tries to remove the lock.
Separately, posix_lock_file() could also fail to
remove a lock due to GFP_KERNEL allocation failure (when splitting a range
in the middle).
After the bug has been triggered, use-after-free reads will occur in
lock_get_status() when userspace reads /proc/locks. This can likely be used
to read arbitrary kernel memory, but can't corrupt kernel memory.
Fix it by calling locks_remove_posix() instead, which is designed to
reliably get rid of POSIX locks associated with the given file and
files_struct and is also used by filp_flush().
CVE-2024-42093:In the Linux kernel, the following vulnerability has been resolved:
net/dpaa2: Avoid explicit cpumask var allocation on stack
For CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumask
variable on stack is not recommended since it can cause potential stack
overflow.
Instead, kernel code should always use *cpumask_var API(s) to allocate
cpumask var in config-neutral way, leaving allocation strategy to
CONFIG_CPUMASK_OFFSTACK.
Use *cpumask_var API(s) to address it.
CVE-2023-52888:In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Only free buffer VA that is not NULL
In the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostly
called only when the buffer to free exists, there are some instances
that didn't do the check and triggered warnings in practice.
We believe those checks were forgotten unintentionally. Add the checks
back to fix the warnings.
CVE-2024-41078:In the Linux kernel, the following vulnerability has been resolved:
btrfs: qgroup: fix quota root leak after quota disable failure
If during the quota disable we fail when cleaning the quota tree or when
deleting the root from the root tree, we jump to the 'out' label without
ever dropping the reference on the quota root, resulting in a leak of the
root since fs_info-&gt;quota_root is no longer pointing to the root (we have
set it to NULL just before those steps).
Fix this by always doing a btrfs_put_root() call under the 'out' label.
This is a problem that exists since qgroups were first added in 2012 by
commit bed92eae26cc (&quot;Btrfs: qgroup implementation and prototypes&quot;), but
back then we missed a kfree on the quota root and free_extent_buffer()
calls on its root and commit root nodes, since back then roots were not
yet reference counted.
CVE-2024-41027:In the Linux kernel, the following vulnerability has been resolved:
Fix userfaultfd_api to return EINVAL as expected
Currently if we request a feature that is not set in the Kernel config we
fail silently and return all the available features.  However, the man
page indicates we should return an EINVAL.
We need to fix this issue since we can end up with a Kernel warning should
a program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel with
the config not set with this feature.
 [  200.812896] WARNING: CPU: 91 PID: 13634 at mm/memory.c:1660 zap_pte_range+0x43d/0x660
 [  200.820738] Modules linked in:
 [  200.869387] CPU: 91 PID: 13634 Comm: userfaultfd Kdump: loaded Not tainted 6.9.0-rc5+ #8
 [  200.877477] Hardware name: Dell Inc. PowerEdge R6525/0N7YGH, BIOS 2.7.3 03/30/2022
 [  200.885052] RIP: 0010:zap_pte_range+0x43d/0x660
CVE-2021-47582:In the Linux kernel, the following vulnerability has been resolved:
USB: core: Make do_proc_control() and do_proc_bulk() killable
The USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invoke
usb_start_wait_urb(), which contains an uninterruptible wait with a
user-specified timeout value.  If timeout value is very large and the
device being accessed does not respond in a reasonable amount of time,
the kernel will complain about &quot;Task X blocked for more than N
seconds&quot;, as found in testing by syzbot:
INFO: task syz-executor.0:8700 blocked for more than 143 seconds.
      Not tainted 5.14.0-rc7-syzkaller #0
&quot;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&quot; disables this message.
task:syz-executor.0  state:D stack:23192 pid: 8700 ppid:  8455 flags:0x00004004
Call Trace:
 context_switch kernel/sched/core.c:4681 [inline]
 __schedule+0xc07/0x11f0 kernel/sched/core.c:5938
 schedule+0x14b/0x210 kernel/sched/core.c:6017
 schedule_timeout+0x98/0x2f0 kernel/time/timer.c:1857
 do_wait_for_common+0x2da/0x480 kernel/sched/completion.c:85
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion_timeout+0x46/0x60 kernel/sched/completion.c:157
 usb_start_wait_urb+0x167/0x550 drivers/usb/core/message.c:63
 do_proc_bulk+0x978/0x1080 drivers/usb/core/devio.c:1236
 proc_bulk drivers/usb/core/devio.c:1273 [inline]
 usbdev_do_ioctl drivers/usb/core/devio.c:2547 [inline]
 usbdev_ioctl+0x3441/0x6b10 drivers/usb/core/devio.c:2713
...
To fix this problem, this patch replaces usbfs's calls to
usb_control_msg() and usb_bulk_msg() with special-purpose code that
does essentially the same thing (as recommended in the comment for
usb_start_wait_urb()), except that it always uses a killable wait and
it uses GFP_KERNEL rather than GFP_NOIO.
CVE-2024-41034:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix kernel bug on rename operation of broken directory
Syzbot reported that in rename directory operation on broken directory on
nilfs2, __block_write_begin_int() called to prepare block write may fail
BUG_ON check for access exceeding the folio/page size.
This is because nilfs_dotdot(), which gets parent directory reference
entry (&quot;..&quot;) of the directory to be moved or renamed, does not check
consistency enough, and may return location exceeding folio/page size for
broken directories.
Fix this issue by checking required directory entries (&quot;.&quot; and &quot;..&quot;) in
the first chunk of the directory in nilfs_dotdot().
CVE-2024-42157:In the Linux kernel, the following vulnerability has been resolved:
s390/pkey: Wipe sensitive data on failure
Wipe sensitive data from stack also if the copy_to_user() fails.
CVE-2022-48827:In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix the behavior of READ near OFFSET_MAX
Dan Aloni reports:
&gt; Due to commit 8cfb9015280d (&quot;NFS: Always provide aligned buffers to
&gt; the RPC read layers&quot;) on the client, a read of 0xfff is aligned up
&gt; to server rsize of 0x1000.
&gt;
&gt; As a result, in a test where the server has a file of size
&gt; 0x7fffffffffffffff, and the client tries to read from the offset
&gt; 0x7ffffffffffff000, the read causes loff_t overflow in the server
&gt; and it returns an NFS code of EINVAL to the client. The client as
&gt; a result indefinitely retries the request.
The Linux NFS client does not handle NFS?ERR_INVAL, even though all
NFS specifications permit servers to return that status code for a
READ.
Instead of NFS?ERR_INVAL, have out-of-range READ requests succeed
and return a short result. Set the EOF flag in the result to prevent
the client from retrying the READ request. This behavior appears to
be consistent with Solaris NFS servers.
Note that NFSv3 and NFSv4 use u64 offset values on the wire. These
must be converted to loff_t internally before use -- an implicit
type cast is not adequate for this purpose. Otherwise VFS checks
against sb-&gt;s_maxbytes do not work properly.
CVE-2024-42128:In the Linux kernel, the following vulnerability has been resolved:
leds: an30259a: Use devm_mutex_init() for mutex initialization
In this driver LEDs are registered using devm_led_classdev_register()
so they are automatically unregistered after module's remove() is done.
led_classdev_unregister() calls module's led_set_brightness() to turn off
the LEDs and that callback uses mutex which was destroyed already
in module's remove() so use devm API instead.
CVE-2024-40942:In the Linux kernel, the following vulnerability has been resolved:
wifi: mac80211: mesh: Fix leak of mesh_preq_queue objects
The hwmp code use objects of type mesh_preq_queue, added to a list in
ieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpath
gets deleted, ex mesh interface is removed, the entries in that list will
never get cleaned. Fix this by flushing all corresponding items of the
preq_queue in mesh_path_flush_pending().
This should take care of KASAN reports like this:
unreferenced object 0xffff00000668d800 (size 128):
  comm &quot;kworker/u8:4&quot;, pid 67, jiffies 4295419552 (age 1836.444s)
  hex dump (first 32 bytes):
    00 1f 05 09 00 00 ff ff 00 d5 68 06 00 00 ff ff  ..........h.....
    8e 97 ea eb 3e b8 01 00 00 00 00 00 00 00 00 00  ....&gt;...........
  backtrace:
    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c
    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80
    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8
    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c
    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4
    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764
    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4
    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440
    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c
    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4
    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508
    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c
    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634
    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4
    [&lt;000000005fccd770&gt;] ret_from_fork+0x10/0x20
unreferenced object 0xffff000009051f00 (size 128):
  comm &quot;kworker/u8:4&quot;, pid 67, jiffies 4295419553 (age 1836.440s)
  hex dump (first 32 bytes):
    90 d6 92 0d 00 00 ff ff 00 d8 68 06 00 00 ff ff  ..........h.....
    36 27 92 e4 02 e0 01 00 00 58 79 06 00 00 ff ff  6'.......Xy.....
  backtrace:
    [&lt;000000007302a0b6&gt;] __kmem_cache_alloc_node+0x1e0/0x35c
    [&lt;00000000049bd418&gt;] kmalloc_trace+0x34/0x80
    [&lt;0000000000d792bb&gt;] mesh_queue_preq+0x44/0x2a8
    [&lt;00000000c99c3696&gt;] mesh_nexthop_resolve+0x198/0x19c
    [&lt;00000000926bf598&gt;] ieee80211_xmit+0x1d0/0x1f4
    [&lt;00000000fc8c2284&gt;] __ieee80211_subif_start_xmit+0x30c/0x764
    [&lt;000000005926ee38&gt;] ieee80211_subif_start_xmit+0x9c/0x7a4
    [&lt;000000004c86e916&gt;] dev_hard_start_xmit+0x174/0x440
    [&lt;0000000023495647&gt;] __dev_queue_xmit+0xe24/0x111c
    [&lt;00000000cfe9ca78&gt;] batadv_send_skb_packet+0x180/0x1e4
    [&lt;000000007bacc5d5&gt;] batadv_v_elp_periodic_work+0x2f4/0x508
    [&lt;00000000adc3cd94&gt;] process_one_work+0x4b8/0xa1c
    [&lt;00000000b36425d1&gt;] worker_thread+0x9c/0x634
    [&lt;0000000005852dd5&gt;] kthread+0x1bc/0x1c4
    [&lt;000000005fccd770&gt;] ret_from_fork+0x10/0x20
CVE-2024-42154:In the Linux kernel, the following vulnerability has been resolved:
tcp_metrics: validate source addr length
I don't see anything checking that TCP_METRICS_ATTR_SADDR_IPV4
is at least 4 bytes long, and the policy doesn't have an entry
for this attribute at all (neither does it for IPv6 but v6 is
manually validated).
CVE-2024-41065:In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Whitelist dtl slub object for copying to userspace
Reading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*
results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled as
shown below.
    kernel BUG at mm/usercopy.c:102!
    Oops: Exception in kernel mode, sig: 5 [#1]
    LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
    Modules linked in: xfs libcrc32c dm_service_time sd_mod t10_pi sg ibmvfc
    scsi_transport_fc ibmveth pseries_wdt dm_multipath dm_mirror dm_region_hash dm_log dm_mod fuse
    CPU: 27 PID: 1815 Comm: python3 Not tainted 6.10.0-rc3 #85
    Hardware name: IBM,9040-MRX POWER10 (raw) 0x800200 0xf000006 of:IBM,FW1060.00 (NM1060_042) hv:phyp pSeries
    NIP:  c0000000005d23d4 LR: c0000000005d23d0 CTR: 00000000006ee6f8
    REGS: c000000120c078c0 TRAP: 0700   Not tainted  (6.10.0-rc3)
    MSR:  8000000000029033 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  CR: 2828220f  XER: 0000000e
    CFAR: c0000000001fdc80 IRQMASK: 0
    [ ... GPRs omitted ... ]
    NIP [c0000000005d23d4] usercopy_abort+0x78/0xb0
    LR [c0000000005d23d0] usercopy_abort+0x74/0xb0
    Call Trace:
     usercopy_abort+0x74/0xb0 (unreliable)
     __check_heap_object+0xf8/0x120
     check_heap_object+0x218/0x240
     __check_object_size+0x84/0x1a4
     dtl_file_read+0x17c/0x2c4
     full_proxy_read+0x8c/0x110
     vfs_read+0xdc/0x3a0
     ksys_read+0x84/0x144
     system_call_exception+0x124/0x330
     system_call_vectored_common+0x15c/0x2ec
    --- interrupt: 3000 at 0x7fff81f3ab34
Commit 6d07d1cd300f (&quot;usercopy: Restrict non-usercopy caches to size 0&quot;)
requires that only whitelisted areas in slab/slub objects can be copied to
userspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.
Dtl contains hypervisor dispatch events which are expected to be read by
privileged users. Hence mark this safe for user access.
Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist the
entire object.
CVE-2024-42095:In the Linux kernel, the following vulnerability has been resolved:
serial: 8250_omap: Implementation of Errata i2310
As per Errata i2310[0], Erroneous timeout can be triggered,
if this Erroneous interrupt is not cleared then it may leads
to storm of interrupts, therefore apply Errata i2310 solution.
[0] https://www.ti.com/lit/pdf/sprz536 page 23
CVE-2024-42114:In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM values
syzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUM
to 2^31.
We had a similar issue in sch_fq, fixed with commit
d9e15a273306 (&quot;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM&quot;)
watchdog: BUG: soft lockup - CPU#1 stuck for 26s! [kworker/1:0:24]
Modules linked in:
irq event stamp: 131135
 hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] __exit_to_kernel_mode arch/arm64/kernel/entry-common.c:85 [inline]
 hardirqs last  enabled at (131134): [&lt;ffff80008ae8778c&gt;] exit_to_kernel_mode+0xdc/0x10c arch/arm64/kernel/entry-common.c:95
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] __el1_irq arch/arm64/kernel/entry-common.c:533 [inline]
 hardirqs last disabled at (131135): [&lt;ffff80008ae85378&gt;] el1_interrupt+0x24/0x68 arch/arm64/kernel/entry-common.c:551
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_hh_init net/core/neighbour.c:1538 [inline]
 softirqs last  enabled at (125892): [&lt;ffff80008907e82c&gt;] neigh_resolve_output+0x268/0x658 net/core/neighbour.c:1553
 softirqs last disabled at (125896): [&lt;ffff80008904166c&gt;] local_bh_disable+0x10/0x34 include/linux/bottom_half.h:19
CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024
Workqueue: mld mld_ifc_work
pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
 pc : __list_del include/linux/list.h:195 [inline]
 pc : __list_del_entry include/linux/list.h:218 [inline]
 pc : list_move_tail include/linux/list.h:310 [inline]
 pc : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
 pc : ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
 lr : __list_del_entry include/linux/list.h:218 [inline]
 lr : list_move_tail include/linux/list.h:310 [inline]
 lr : fq_tin_dequeue include/net/fq_impl.h:112 [inline]
 lr : ieee80211_tx_dequeue+0x67c/0x3b4c net/mac80211/tx.c:3854
sp : ffff800093d36700
x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000
x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0
x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0
x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0
x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8
x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffff
x11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000
x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000
x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fc
x2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470
Call trace:
  __list_del include/linux/list.h:195 [inline]
  __list_del_entry include/linux/list.h:218 [inline]
  list_move_tail include/linux/list.h:310 [inline]
  fq_tin_dequeue include/net/fq_impl.h:112 [inline]
  ieee80211_tx_dequeue+0x6b8/0x3b4c net/mac80211/tx.c:3854
  wake_tx_push_queue net/mac80211/util.c:294 [inline]
  ieee80211_handle_wake_tx_queue+0x118/0x274 net/mac80211/util.c:315
  drv_wake_tx_queue net/mac80211/driver-ops.h:1350 [inline]
  schedule_and_wake_txq net/mac80211/driver-ops.h:1357 [inline]
  ieee80211_queue_skb+0x18e8/0x2244 net/mac80211/tx.c:1664
  ieee80211_tx+0x260/0x400 net/mac80211/tx.c:1966
  ieee80211_xmit+0x278/0x354 net/mac80211/tx.c:2062
  __ieee80211_subif_start_xmit+0xab8/0x122c net/mac80211/tx.c:4338
  ieee80211_subif_start_xmit+0xe0/0x438 net/mac80211/tx.c:4532
  __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+0x27c/0x938 net/core/dev.c:3547
  __dev_queue_xmit+0x1678/0x33fc net/core/dev.c:4341
  dev_queue_xmit include/linux/netdevice.h:3091 [inline]
  neigh_resolve_output+0x558/0x658 net/core/neighbour.c:1563
  neigh_output include/net/neighbour.h:542 [inline]
  ip6_fini
---truncated---
CVE-2024-42102:In the Linux kernel, the following vulnerability has been resolved:
Revert &quot;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again&quot;
Patch series &quot;mm: Avoid possible overflows in dirty throttling&quot;.
Dirty throttling logic assumes dirty limits in page units fit into
32-bits.  This patch series makes sure this is true (see patch 2/2 for
more details).
This patch (of 2):
This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.
The commit is broken in several ways.  Firstly, the removed (u64) cast
from the multiplication will introduce a multiplication overflow on 32-bit
archs if wb_thresh * bg_thresh &gt;= 1&lt;&lt;32 (which is actually common - the
default settings with 4GB of RAM will trigger this).  Secondly, the
div64_u64() is unnecessarily expensive on 32-bit archs.  We have
div64_ul() in case we want to be safe &amp; cheap.  Thirdly, if dirty
thresholds are larger than 1&lt;&lt;32 pages, then dirty balancing is going to
blow up in many other spectacular ways anyway so trying to fix one
possible overflow is just moot.
CVE-2024-42225:In the Linux kernel, the following vulnerability has been resolved:wifi: mt76: replace skb_put with skb_put_zeroAvoid potentially reusing uninitialized data
CVE-2024-41042:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: prefer nft_chain_validate
nft_chain_validate already performs loop detection because a cycle will
result in a call stack overflow (ctx-&gt;level &gt;= NFT_JUMP_STACK_SIZE).
It also follows maps via -&gt;validate callback in nft_lookup, so there
appears no reason to iterate the maps again.
nf_tables_check_loops() and all its helper functions can be removed.
This improves ruleset load time significantly, from 23s down to 12s.
This also fixes a crash bug. Old loop detection code can result in
unbounded recursion:
BUG: TASK stack guard page was hit at ....
Oops: stack guard page: 0000 [#1] PREEMPT SMP KASAN
CPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1
[..]
with a suitable ruleset during validation of register stores.
I can't see any actual reason to attempt to check for this from
nft_validate_register_store(), at this point the transaction is still in
progress, so we don't have a full picture of the rule graph.
For nf-next it might make sense to either remove it or make this depend
on table-&gt;validate_state in case we could catch an error earlier
(for improved error reporting to userspace).
CVE-2024-42247:In the Linux kernel, the following vulnerability has been resolved:
wireguard: allowedips: avoid unaligned 64-bit memory accesses
On the parisc platform, the kernel issues kernel warnings because
swap_endian() tries to load a 128-bit IPv6 address from an unaligned
memory location:
 Kernel: unaligned access to 0x55f4688c in wg_allowedips_insert_v6+0x2c/0x80 [wireguard] (iir 0xf3010df)
 Kernel: unaligned access to 0x55f46884 in wg_allowedips_insert_v6+0x38/0x80 [wireguard] (iir 0xf2010dc)
Avoid such unaligned memory accesses by instead using the
get_unaligned_be64() helper macro.
[Jason: replace src[8] in original patch with src+8]
CVE-2024-42223:In the Linux kernel, the following vulnerability has been resolved:
media: dvb-frontends: tda10048: Fix integer overflow
state-&gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integer
when multiplied by pll_mfactor.
Create a new 64 bit variable to hold the calculations.
CVE-2024-42246:In the Linux kernel, the following vulnerability has been resolved:
net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socket
When using a BPF program on kernel_connect(), the call can return -EPERM. This
causes xs_tcp_setup_socket() to loop forever, filling up the syslog and causing
the kernel to potentially freeze up.
Neil suggested:
  This will propagate -EPERM up into other layers which might not be ready
  to handle it. It might be safer to map EPERM to an error we would be more
  likely to expect from the network system - such as ECONNREFUSED or ENETDOWN.
ECONNREFUSED as error seems reasonable. For programs setting a different error
can be out of reach (see handling in 4fbac77d2d09) in particular on kernels
which do not have f10d05966196 (&quot;bpf: Make BPF_PROG_RUN_ARRAY return -err
instead of allow boolean&quot;), thus given that it is better to simply remap for
consistent behavior. UDP does handle EPERM in xs_udp_send_request().
CVE-2024-42244:In the Linux kernel, the following vulnerability has been resolved:
USB: serial: mos7840: fix crash on resume
Since commit c49cfa917025 (&quot;USB: serial: use generic method if no
alternative is provided in usb serial layer&quot;), USB serial core calls the
generic resume implementation when the driver has not provided one.
This can trigger a crash on resume with mos7840 since support for
multiple read URBs was added back in 2011. Specifically, both port read
URBs are now submitted on resume for open ports, but the context pointer
of the second URB is left set to the core rather than mos7840 port
structure.
Fix this by implementing dedicated suspend and resume functions for
mos7840.
Tested with Delock 87414 USB 2.0 to 4x serial adapter.
[ johan: analyse crash and rewrite commit message; set busy flag on
         resume; drop bulk-in check; drop unnecessary usb_kill_urb() ]
CVE-2024-41092:In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gt: Fix potential UAF by revoke of fence registers
CI has been sporadically reporting the following issue triggered by
igt@i915_selftest@live@hangcheck on ADL-P and similar machines:
&lt;6&gt; [414.049203] i915: Running intel_hangcheck_live_selftests/igt_reset_evict_fence
...
&lt;6&gt; [414.068804] i915 0000:00:02.0: [drm] GT0: GUC: submission enabled
&lt;6&gt; [414.068812] i915 0000:00:02.0: [drm] GT0: GUC: SLPC enabled
&lt;3&gt; [414.070354] Unable to pin Y-tiled fence; err:-4
&lt;3&gt; [414.071282] i915_vma_revoke_fence:301 GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active))
...
&lt;4&gt;[  609.603992] ------------[ cut here ]------------
&lt;2&gt;[  609.603995] kernel BUG at drivers/gpu/drm/i915/gt/intel_ggtt_fencing.c:301!
&lt;4&gt;[  609.604003] invalid opcode: 0000 [#1] PREEMPT SMP NOPTI
&lt;4&gt;[  609.604006] CPU: 0 PID: 268 Comm: kworker/u64:3 Tainted: G     U  W          6.9.0-CI_DRM_14785-g1ba62f8cea9c+ #1
&lt;4&gt;[  609.604008] Hardware name: Intel Corporation Alder Lake Client Platform/AlderLake-P DDR4 RVP, BIOS RPLPFWI1.R00.4035.A00.2301200723 01/20/2023
&lt;4&gt;[  609.604010] Workqueue: i915 __i915_gem_free_work [i915]
&lt;4&gt;[  609.604149] RIP: 0010:i915_vma_revoke_fence+0x187/0x1f0 [i915]
...
&lt;4&gt;[  609.604271] Call Trace:
&lt;4&gt;[  609.604273]  &lt;TASK&gt;
...
&lt;4&gt;[  609.604716]  __i915_vma_evict+0x2e9/0x550 [i915]
&lt;4&gt;[  609.604852]  __i915_vma_unbind+0x7c/0x160 [i915]
&lt;4&gt;[  609.604977]  force_unbind+0x24/0xa0 [i915]
&lt;4&gt;[  609.605098]  i915_vma_destroy+0x2f/0xa0 [i915]
&lt;4&gt;[  609.605210]  __i915_gem_object_pages_fini+0x51/0x2f0 [i915]
&lt;4&gt;[  609.605330]  __i915_gem_free_objects.isra.0+0x6a/0xc0 [i915]
&lt;4&gt;[  609.605440]  process_scheduled_works+0x351/0x690
...
In the past, there were similar failures reported by CI from other IGT
tests, observed on other platforms.
Before commit 63baf4f3d587 (&quot;drm/i915/gt: Only wait for GPU activity
before unbinding a GGTT fence&quot;), i915_vma_revoke_fence() was waiting for
idleness of vma-&gt;active via fence_update().   That commit introduced
vma-&gt;fence-&gt;active in order for the fence_update() to be able to wait
selectively on that one instead of vma-&gt;active since only idleness of
fence registers was needed.  But then, another commit 0d86ee35097a
(&quot;drm/i915/gt: Make fence revocation unequivocal&quot;) replaced the call to
fence_update() in i915_vma_revoke_fence() with only fence_write(), and
also added that GEM_BUG_ON(!i915_active_is_idle(&amp;fence-&gt;active)) in front.
No justification was provided on why we might then expect idleness of
vma-&gt;fence-&gt;active without first waiting on it.
The issue can be potentially caused by a race among revocation of fence
registers on one side and sequential execution of signal callbacks invoked
on completion of a request that was using them on the other, still
processed in parallel to revocation of those fence registers.  Fix it by
waiting for idleness of vma-&gt;fence-&gt;active in i915_vma_revoke_fence().
(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)
CVE-2024-42087:In the Linux kernel, the following vulnerability has been resolved:
drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleep
The ilitek-ili9881c controls the reset GPIO using the non-sleeping
gpiod_set_value() function. This complains loudly when the GPIO
controller needs to sleep. As the caller can sleep, use
gpiod_set_value_cansleep() to fix the issue.
CVE-2024-42143:In the Linux kernel, the following vulnerability has been resolved:
orangefs: fix out-of-bounds fsid access
Arnd Bergmann sent a patch to fsdevel, he says:
&quot;orangefs_statfs() copies two consecutive fields of the superblock into
the statfs structure, which triggers a warning from the string fortification
helpers&quot;
Jan Kara suggested an alternate way to do the patch to make it more readable.
I ran both ideas through xfstests and both seem fine. This patch
is based on Jan Kara's suggestion.
CVE-2024-42229:In the Linux kernel, the following vulnerability has been resolved:
crypto: aead,cipher - zeroize key buffer after use
I.G 9.7.B for FIPS 140-3 specifies that variables temporarily holding
cryptographic information should be zeroized once they are no longer
needed. Accomplish this by using kfree_sensitive for buffers that
previously held the private key.
CVE-2024-42156:In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of clear-key structures on failureWipe all sensitive data from stack for all IOCTLs, which convert aclear-key into a protected- or secure-key.
CVE-2024-35840:In the Linux kernel, the following vulnerability has been resolved:
mptcp: use OPTION_MPTCP_MPJ_SYNACK in subflow_finish_connect()
subflow_finish_connect() uses four fields (backup, join_id, thmac, none)
that may contain garbage unless OPTION_MPTCP_MPJ_SYNACK has been set
in mptcp_parse_option()
CVE-2024-36971:In the Linux kernel, the following vulnerability has been resolved:net: fix __dst_negative_advice() race__dst_negative_advice() does not enforce proper RCU rules whensk-&gt;dst_cache must be cleared, leading to possible UAF.RCU rules are that we must first clear sk-&gt;sk_dst_cache,then call dst_release(old_dst).Note that sk_dst_reset(sk) is implementing this protocol correctly,while __dst_negative_advice() uses the wrong order.Given that ip6_negative_advice() has special logicagainst RTF_CACHE, this means each of the three -&gt;negative_advice()existing methods must perform the sk_dst_reset() themselves.Note the check against NULL dst is centralized in__dst_negative_advice(), there is no need to duplicateit in various callbacks.Many thanks to Clement Lecigne for tracking this issue.This old bug became visible after the blamed commit, using UDP sockets.
CVE-2024-37356:In the Linux kernel, the following vulnerability has been resolved:
tcp: Fix shift-out-of-bounds in dctcp_update_alpha().
In dctcp_update_alpha(), we use a module parameter dctcp_shift_g
as follows:
  alpha -= min_not_zero(alpha, alpha &gt;&gt; dctcp_shift_g);
  ...
  delivered_ce &lt;&lt;= (10 - dctcp_shift_g);
It seems syzkaller started fuzzing module parameters and triggered
shift-out-of-bounds [0] by setting 100 to dctcp_shift_g:
  memcpy((void*)0x20000080,
         &quot;/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000&quot;, 47);
  res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,
                /*flags=*/2ul, /*mode=*/0ul);
  memcpy((void*)0x20000000, &quot;100\000&quot;, 4);
  syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);
Let's limit the max value of dctcp_shift_g by param_set_uint_minmax().
With this patch:
  # echo 10 &gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g
  # cat /sys/module/tcp_dctcp/parameters/dctcp_shift_g
  10
  # echo 11 &gt; /sys/module/tcp_dctcp/parameters/dctcp_shift_g
  -bash: echo: write error: Invalid argument
[0]:
UBSAN: shift-out-of-bounds in net/ipv4/tcp_dctcp.c:143:12
shift exponent 100 is too large for 32-bit type 'u32' (aka 'unsigned int')
CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2
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+0x201/0x300 lib/dump_stack.c:114
 ubsan_epilogue lib/ubsan.c:231 [inline]
 __ubsan_handle_shift_out_of_bounds+0x346/0x3a0 lib/ubsan.c:468
 dctcp_update_alpha+0x540/0x570 net/ipv4/tcp_dctcp.c:143
 tcp_in_ack_event net/ipv4/tcp_input.c:3802 [inline]
 tcp_ack+0x17b1/0x3bc0 net/ipv4/tcp_input.c:3948
 tcp_rcv_state_process+0x57a/0x2290 net/ipv4/tcp_input.c:6711
 tcp_v4_do_rcv+0x764/0xc40 net/ipv4/tcp_ipv4.c:1937
 sk_backlog_rcv include/net/sock.h:1106 [inline]
 __release_sock+0x20f/0x350 net/core/sock.c:2983
 release_sock+0x61/0x1f0 net/core/sock.c:3549
 mptcp_subflow_shutdown+0x3d0/0x620 net/mptcp/protocol.c:2907
 mptcp_check_send_data_fin+0x225/0x410 net/mptcp/protocol.c:2976
 __mptcp_close+0x238/0xad0 net/mptcp/protocol.c:3072
 mptcp_close+0x2a/0x1a0 net/mptcp/protocol.c:3127
 inet_release+0x190/0x1f0 net/ipv4/af_inet.c:437
 __sock_release net/socket.c:659 [inline]
 sock_close+0xc0/0x240 net/socket.c:1421
 __fput+0x41b/0x890 fs/file_table.c:422
 task_work_run+0x23b/0x300 kernel/task_work.c:180
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0x9c8/0x2540 kernel/exit.c:878
 do_group_exit+0x201/0x2b0 kernel/exit.c:1027
 __do_sys_exit_group kernel/exit.c:1038 [inline]
 __se_sys_exit_group kernel/exit.c:1036 [inline]
 __x64_sys_exit_group+0x3f/0x40 kernel/exit.c:1036
 do_syscall_x64 arch/x86/entry/common.c:52 [inline]
 do_syscall_64+0xe4/0x240 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x67/0x6f
RIP: 0033:0x7f6c2b5005b6
Code: Unable to access opcode bytes at 0x7f6c2b50058c.
RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7
RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6
RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001
RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0
R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0
R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001
 &lt;/TASK&gt;
CVE-2024-35879:In the Linux kernel, the following vulnerability has been resolved:
of: dynamic: Synchronize of_changeset_destroy() with the devlink removals
In the following sequence:
  1) of_platform_depopulate()
  2) of_overlay_remove()
During the step 1, devices are destroyed and devlinks are removed.
During the step 2, OF nodes are destroyed but
__of_changeset_entry_destroy() can raise warnings related to missing
of_node_put():
  ERROR: memory leak, expected refcount 1 instead of 2 ...
Indeed, during the devlink removals performed at step 1, the removal
itself releasing the device (and the attached of_node) is done by a job
queued in a workqueue and so, it is done asynchronously with respect to
function calls.
When the warning is present, of_node_put() will be called but wrongly
too late from the workqueue job.
In order to be sure that any ongoing devlink removals are done before
the of_node destruction, synchronize the of_changeset_destroy() with the
devlink removals.
CVE-2024-39362:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-27415:In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: confirm multicast packets before passing them up the stack
conntrack nf_confirm logic cannot handle cloned skbs referencing
the same nf_conn entry, which will happen for multicast (broadcast)
frames on bridges.
 Example:
    macvlan0
       |
      br0
     /  \
  ethX    ethY
 ethX (or Y) receives a L2 multicast or broadcast packet containing
 an IP packet, flow is not yet in conntrack table.
 1. skb passes through bridge and fake-ip (br_netfilter)Prerouting.
    -&gt; skb-&gt;_nfct now references a unconfirmed entry
 2. skb is broad/mcast packet. bridge now passes clones out on each bridge
    interface.
 3. skb gets passed up the stack.
 4. In macvlan case, macvlan driver retains clone(s) of the mcast skb
    and schedules a work queue to send them out on the lower devices.
    The clone skb-&gt;_nfct is not a copy, it is the same entry as the
    original skb.  The macvlan rx handler then returns RX_HANDLER_PASS.
 5. Normal conntrack hooks (in NF_INET_LOCAL_IN) confirm the orig skb.
The Macvlan broadcast worker and normal confirm path will race.
This race will not happen if step 2 already confirmed a clone. In that
case later steps perform skb_clone() with skb-&gt;_nfct already confirmed (in
hash table).  This works fine.
But such confirmation won't happen when eb/ip/nftables rules dropped the
packets before they reached the nf_confirm step in postrouting.
Pablo points out that nf_conntrack_bridge doesn't allow use of stateful
nat, so we can safely discard the nf_conn entry and let inet call
conntrack again.
This doesn't work for bridge netfilter: skb could have a nat
transformation. Also bridge nf prevents re-invocation of inet prerouting
via 'sabotage_in' hook.
Work around this problem by explicit confirmation of the entry at LOCAL_IN
time, before upper layer has a chance to clone the unconfirmed entry.
The downside is that this disables NAT and conntrack helpers.
Alternative fix would be to add locking to all code parts that deal with
unconfirmed packets, but even if that could be done in a sane way this
opens up other problems, for example:
-m physdev --physdev-out eth0 -j SNAT --snat-to 1.2.3.4
-m physdev --physdev-out eth1 -j SNAT --snat-to 1.2.3.5
For multicast case, only one of such conflicting mappings will be
created, conntrack only handles 1:1 NAT mappings.
Users should set create a setup that explicitly marks such traffic
NOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypass
them, ruleset might have accept rules for untracked traffic already,
so user-visible behaviour would change.
CVE-2024-35839:In the Linux kernel, the following vulnerability has been resolved:
netfilter: bridge: replace physindev with physinif in nf_bridge_info
An skb can be added to a neigh-&gt;arp_queue while waiting for an arp
reply. Where original skb's skb-&gt;dev can be different to neigh's
neigh-&gt;dev. For instance in case of bridging dnated skb from one veth to
another, the skb would be added to a neigh-&gt;arp_queue of the bridge.
As skb-&gt;dev can be reset back to nf_bridge-&gt;physindev and used, and as
there is no explicit mechanism that prevents this physindev from been
freed under us (for instance neigh_flush_dev doesn't cleanup skbs from
different device's neigh queue) we can crash on e.g. this stack:
arp_process
  neigh_update
    skb = __skb_dequeue(&amp;neigh-&gt;arp_queue)
      neigh_resolve_output(..., skb)
        ...
          br_nf_dev_xmit
            br_nf_pre_routing_finish_bridge_slow
              skb-&gt;dev = nf_bridge-&gt;physindev
              br_handle_frame_finish
Let's use plain ifindex instead of net_device link. To peek into the
original net_device we will use dev_get_by_index_rcu(). Thus either we
get device and are safe to use it or we don't get it and drop skb.
CVE-2024-35819:In the Linux kernel, the following vulnerability has been resolved:
soc: fsl: qbman: Use raw spinlock for cgr_lock
smp_call_function always runs its callback in hard IRQ context, even on
PREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlock
for cgr_lock to ensure we aren't waiting on a sleeping task.
Although this bug has existed for a while, it was not apparent until
commit ef2a8d5478b9 (&quot;net: dpaa: Adjust queue depth on rate change&quot;)
which invokes smp_call_function_single via qman_update_cgr_safe every
time a link goes up or down.
CVE-2021-47366:In the Linux kernel, the following vulnerability has been resolved:
afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS server
AFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, and
Linux's afs client switches between them when talking to a non-YFS server
if the read size, the file position or the sum of the two have the upper 32
bits set of the 64-bit value.
This is a problem, however, since the file position and length fields of
FS.FetchData are *signed* 32-bit values.
Fix this by capturing the capability bits obtained from the fileserver when
it's sent an FS.GetCapabilities RPC, rather than just discarding them, and
then picking out the VICED_CAPABILITY_64BITFILES flag.  This can then be
used to decide whether to use FS.FetchData or FS.FetchData64 - and also
FS.StoreData or FS.StoreData64 - rather than using upper_32_bits() to
switch on the parameter values.
This capabilities flag could also be used to limit the maximum size of the
file, but all servers must be checked for that.
Note that the issue does not exist with FS.StoreData - that uses *unsigned*
32-bit values.  It's also not a problem with Auristor servers as its
YFS.FetchData64 op uses unsigned 64-bit values.
This can be tested by cloning a git repo through an OpenAFS client to an
OpenAFS server and then doing &quot;git status&quot; on it from a Linux afs
client[1].  Provided the clone has a pack file that's in the 2G-4G range,
the git status will show errors like:
	error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
	error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index
This can be observed in the server's FileLog with something like the
following appearing:
Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001
Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154
Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866
...
Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5
Note the file position of 18446744071815340032.  This is the requested file
position sign-extended.
CVE-2024-36968:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: L2CAP: Fix div-by-zero in l2cap_le_flowctl_init()
l2cap_le_flowctl_init() can cause both div-by-zero and an integer
overflow since hdev-&gt;le_mtu may not fall in the valid range.
Move MTU from hci_dev to hci_conn to validate MTU and stop the connection
process earlier if MTU is invalid.
Also, add a missing validation in read_buffer_size() and make it return
an error value if the validation fails.
Now hci_conn_add() returns ERR_PTR() as it can fail due to the both a
kzalloc failure and invalid MTU value.
divide error: 0000 [#1] PREEMPT SMP KASAN NOPTI
CPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014
Workqueue: hci0 hci_rx_work
RIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547
Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c
89 fe 4c 89 e2 89 d9 e8 27 17 0c 00 44 89 f0 31 d2 &lt;66&gt; f7 f3 89 c3 ff c3 4d 8d
b7 88 00 00 00 4c 89 f0 48 c1 e8 03 42
RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246
RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000
RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66f
RBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaa
R10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084
R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000
FS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 l2cap_le_connect_req net/bluetooth/l2cap_core.c:4902 [inline]
 l2cap_le_sig_cmd net/bluetooth/l2cap_core.c:5420 [inline]
 l2cap_le_sig_channel net/bluetooth/l2cap_core.c:5486 [inline]
 l2cap_recv_frame+0xe59d/0x11710 net/bluetooth/l2cap_core.c:6809
 l2cap_recv_acldata+0x544/0x10a0 net/bluetooth/l2cap_core.c:7506
 hci_acldata_packet net/bluetooth/hci_core.c:3939 [inline]
 hci_rx_work+0x5e5/0xb20 net/bluetooth/hci_core.c:4176
 process_one_work kernel/workqueue.c:3254 [inline]
 process_scheduled_works+0x90f/0x1530 kernel/workqueue.c:3335
 worker_thread+0x926/0xe70 kernel/workqueue.c:3416
 kthread+0x2e3/0x380 kernel/kthread.c:388
 ret_from_fork+0x5c/0x90 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
 &lt;/TASK&gt;
Modules linked in:
---[ end trace 0000000000000000 ]---
CVE-2021-47469:In the Linux kernel, the following vulnerability has been resolved:
spi: Fix deadlock when adding SPI controllers on SPI buses
Currently we have a global spi_add_lock which we take when adding new
devices so that we can check that we're not trying to reuse a chip
select that's already controlled.  This means that if the SPI device is
itself a SPI controller and triggers the instantiation of further SPI
devices we trigger a deadlock as we try to register and instantiate
those devices while in the process of doing so for the parent controller
and hence already holding the global spi_add_lock.  Since we only care
about concurrency within a single SPI bus move the lock to be per
controller, avoiding the deadlock.
This can be easily triggered in the case of spi-mux.
CVE-2024-38588:In the Linux kernel, the following vulnerability has been resolved:
ftrace: Fix possible use-after-free issue in ftrace_location()
KASAN reports a bug:
  BUG: KASAN: use-after-free in ftrace_location+0x90/0x120
  Read of size 8 at addr ffff888141d40010 by task insmod/424
  CPU: 8 PID: 424 Comm: insmod Tainted: G        W          6.9.0-rc2+
  [...]
  Call Trace:
   &lt;TASK&gt;
   dump_stack_lvl+0x68/0xa0
   print_report+0xcf/0x610
   kasan_report+0xb5/0xe0
   ftrace_location+0x90/0x120
   register_kprobe+0x14b/0xa40
   kprobe_init+0x2d/0xff0 [kprobe_example]
   do_one_initcall+0x8f/0x2d0
   do_init_module+0x13a/0x3c0
   load_module+0x3082/0x33d0
   init_module_from_file+0xd2/0x130
   __x64_sys_finit_module+0x306/0x440
   do_syscall_64+0x68/0x140
   entry_SYSCALL_64_after_hwframe+0x71/0x79
The root cause is that, in lookup_rec(), ftrace record of some address
is being searched in ftrace pages of some module, but those ftrace pages
at the same time is being freed in ftrace_release_mod() as the
corresponding module is being deleted:
           CPU1                       |      CPU2
  register_kprobes() {                | delete_module() {
    check_kprobe_address_safe() {     |
      arch_check_ftrace_location() {  |
        ftrace_location() {           |
          lookup_rec() // USE!        |   ftrace_release_mod() // Free!
To fix this issue:
  1. Hold rcu lock as accessing ftrace pages in ftrace_location_range();
  2. Use ftrace_location_range() instead of lookup_rec() in
     ftrace_location();
  3. Call synchronize_rcu() before freeing any ftrace pages both in
     ftrace_process_locs()/ftrace_release_mod()/ftrace_free_mem().
CVE-2021-47599:In the Linux kernel, the following vulnerability has been resolved:
btrfs: use latest_dev in btrfs_show_devname
The test case btrfs/238 reports the warning below:
 WARNING: CPU: 3 PID: 481 at fs/btrfs/super.c:2509 btrfs_show_devname+0x104/0x1e8 [btrfs]
 CPU: 2 PID: 1 Comm: systemd Tainted: G        W  O 5.14.0-rc1-custom #72
 Hardware name: QEMU QEMU Virtual Machine, BIOS 0.0.0 02/06/2015
 Call trace:
   btrfs_show_devname+0x108/0x1b4 [btrfs]
   show_mountinfo+0x234/0x2c4
   m_show+0x28/0x34
   seq_read_iter+0x12c/0x3c4
   vfs_read+0x29c/0x2c8
   ksys_read+0x80/0xec
   __arm64_sys_read+0x28/0x34
   invoke_syscall+0x50/0xf8
   do_el0_svc+0x88/0x138
   el0_svc+0x2c/0x8c
   el0t_64_sync_handler+0x84/0xe4
   el0t_64_sync+0x198/0x19c
Reason:
While btrfs_prepare_sprout() moves the fs_devices::devices into
fs_devices::seed_list, the btrfs_show_devname() searches for the devices
and found none, leading to the warning as in above.
Fix:
latest_dev is updated according to the changes to the device list.
That means we could use the latest_dev-&gt;name to show the device name in
/proc/self/mounts, the pointer will be always valid as it's assigned
before the device is deleted from the list in remove or replace.
The RCU protection is sufficient as the device structure is freed after
synchronization.
CVE-2024-38623:In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Use variable length array instead of fixed size
Should fix smatch warning:
	ntfs_set_label() error: __builtin_memcpy() 'uni-&gt;name' too small (20 vs 256)
CVE-2024-26921:In the Linux kernel, the following vulnerability has been resolved:
inet: inet_defrag: prevent sk release while still in use
ip_local_out() and other functions can pass skb-&gt;sk as function argument.
If the skb is a fragment and reassembly happens before such function call
returns, the sk must not be released.
This affects skb fragments reassembled via netfilter or similar
modules, e.g. openvswitch or ct_act.c, when run as part of tx pipeline.
Eric Dumazet made an initial analysis of this bug.  Quoting Eric:
  Calling ip_defrag() in output path is also implying skb_orphan(),
  which is buggy because output path relies on sk not disappearing.
  A relevant old patch about the issue was :
  8282f27449bf (&quot;inet: frag: Always orphan skbs inside ip_defrag()&quot;)
  [..]
  net/ipv4/ip_output.c depends on skb-&gt;sk being set, and probably to an
  inet socket, not an arbitrary one.
  If we orphan the packet in ipvlan, then downstream things like FQ
  packet scheduler will not work properly.
  We need to change ip_defrag() to only use skb_orphan() when really
  needed, ie whenever frag_list is going to be used.
Eric suggested to stash sk in fragment queue and made an initial patch.
However there is a problem with this:
If skb is refragmented again right after, ip_do_fragment() will copy
head-&gt;sk to the new fragments, and sets up destructor to sock_wfree.
IOW, we have no choice but to fix up sk_wmem accouting to reflect the
fully reassembled skb, else wmem will underflow.
This change moves the orphan down into the core, to last possible moment.
As ip_defrag_offset is aliased with sk_buff-&gt;sk member, we must move the
offset into the FRAG_CB, else skb-&gt;sk gets clobbered.
This allows to delay the orphaning long enough to learn if the skb has
to be queued or if the skb is completing the reasm queue.
In the former case, things work as before, skb is orphaned.  This is
safe because skb gets queued/stolen and won't continue past reasm engine.
In the latter case, we will steal the skb-&gt;sk reference, reattach it to
the head skb, and fix up wmem accouting when inet_frag inflates truesize.
CVE-2024-26592:In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix UAF issue in ksmbd_tcp_new_connection()The race is between the handling of a new TCP connection andits disconnection. It leads to UAF on `struct tcp_transport` inksmbd_tcp_new_connection() function.
CVE-2024-38556:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Add a timeout to acquire the command queue semaphore
Prevent forced completion handling on an entry that has not yet been
assigned an index, causing an out of bounds access on idx = -22.
Instead of waiting indefinitely for the sem, blocking flow now waits for
index to be allocated or a sem acquisition timeout before beginning the
timer for FW completion.
Kernel log example:
mlx5_core 0000:06:00.0: wait_func_handle_exec_timeout:1128:(pid 185911): cmd[-22]: CREATE_UCTX(0xa04) No done completion
CVE-2022-48744:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5e: Avoid field-overflowing memcpy()
In preparation for FORTIFY_SOURCE performing compile-time and run-time
field bounds checking for memcpy(), memmove(), and memset(), avoid
intentionally writing across neighboring fields.
Use flexible arrays instead of zero-element arrays (which look like they
are always overflowing) and split the cross-field memcpy() into two halves
that can be appropriately bounds-checked by the compiler.
We were doing:
	#define ETH_HLEN  14
	#define VLAN_HLEN  4
	...
	#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)
	...
        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);
	...
        struct mlx5_wqe_eth_seg  *eseg = &amp;wqe-&gt;eth;
        struct mlx5_wqe_data_seg *dseg = wqe-&gt;data;
	...
	memcpy(eseg-&gt;inline_hdr.start, xdptxd-&gt;data, MLX5E_XDP_MIN_INLINE);
target is wqe-&gt;eth.inline_hdr.start (which the compiler sees as being
2 bytes in size), but copying 18, intending to write across start
(really vlan_tci, 2 bytes). The remaining 16 bytes get written into
wqe-&gt;data[0], covering byte_count (4 bytes), lkey (4 bytes), and addr
(8 bytes).
struct mlx5e_tx_wqe {
        struct mlx5_wqe_ctrl_seg   ctrl;                 /*     0    16 */
        struct mlx5_wqe_eth_seg    eth;                  /*    16    16 */
        struct mlx5_wqe_data_seg   data[];               /*    32     0 */
        /* size: 32, cachelines: 1, members: 3 */
        /* last cacheline: 32 bytes */
};
struct mlx5_wqe_eth_seg {
        u8                         swp_outer_l4_offset;  /*     0     1 */
        u8                         swp_outer_l3_offset;  /*     1     1 */
        u8                         swp_inner_l4_offset;  /*     2     1 */
        u8                         swp_inner_l3_offset;  /*     3     1 */
        u8                         cs_flags;             /*     4     1 */
        u8                         swp_flags;            /*     5     1 */
        __be16                     mss;                  /*     6     2 */
        __be32                     flow_table_metadata;  /*     8     4 */
        union {
                struct {
                        __be16     sz;                   /*    12     2 */
                        u8         start[2];             /*    14     2 */
                } inline_hdr;                            /*    12     4 */
                struct {
                        __be16     type;                 /*    12     2 */
                        __be16     vlan_tci;             /*    14     2 */
                } insert;                                /*    12     4 */
                __be32             trailer;              /*    12     4 */
        };                                               /*    12     4 */
        /* size: 16, cachelines: 1, members: 9 */
        /* last cacheline: 16 bytes */
};
struct mlx5_wqe_data_seg {
        __be32                     byte_count;           /*     0     4 */
        __be32                     lkey;                 /*     4     4 */
        __be64                     addr;                 /*     8     8 */
        /* size: 16, cachelines: 1, members: 3 */
        /* last cacheline: 16 bytes */
};
So, split the memcpy() so the compiler can reason about the buffer
sizes.
&quot;pahole&quot; shows no size nor member offset changes to struct mlx5e_tx_wqe
nor struct mlx5e_umr_wqe. &quot;objdump -d&quot; shows no meaningful object
code changes (i.e. only source line number induced differences and
optimizations).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.89.0.170.u137.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.89.0.170.u137.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.89.0.170.u137.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2286</id>
		<title>An update for libtiff is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7006" id="CVE-2024-7006" title="CVE-2024-7006" type="cve"/>
		</references>
		<description>CVE-2024-7006:A null pointer dereference flaw was found in Libtiff via `tif_dirinfo.c`. This issue may allow an attacker to trigger memory allocation failures through certain means, such as restricting the heap space size or injecting faults, causing a segmentation fault. This can cause an application crash, eventually leading to a denial of service.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="libtiff" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-38.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-devel" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-38.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-static" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-38.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libtiff-tools" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-38.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="libtiff-help" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-help-4.3.0-38.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-4.3.0-38.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-devel" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-devel-4.3.0-38.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-static" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-static-4.3.0-38.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libtiff-tools" release="38.u14.fos23" version="4.3.0">
					<filename>libtiff-tools-4.3.0-38.u14.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2287</id>
		<title>An update for libvpx is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5197" id="CVE-2024-5197" title="CVE-2024-5197" type="cve"/>
		</references>
		<description>CVE-2024-5197:There exists interger overflows in libvpx in versions prior to 1.14.1. Calling vpx_img_alloc() with a large value of the d_w, d_h, or align parameter may result in integer overflows in the calculations of buffer sizes and offsets and some fields of the returned vpx_image_t struct may be invalid. Calling vpx_img_wrap() with a large value of the d_w, d_h, or stride_align parameter may result in integer overflows in the calculations of buffer sizes and offsets and some fields of the returned vpx_image_t struct may be invalid. We recommend upgrading to version 1.14.1 or beyond</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="libvpx" release="12.u4.fos23" version="1.7.0">
					<filename>libvpx-1.7.0-12.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libvpx-devel" release="12.u4.fos23" version="1.7.0">
					<filename>libvpx-devel-1.7.0-12.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libvpx" release="12.u4.fos23" version="1.7.0">
					<filename>libvpx-1.7.0-12.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libvpx-devel" release="12.u4.fos23" version="1.7.0">
					<filename>libvpx-devel-1.7.0-12.u4.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2288</id>
		<title>An update for linux-sgx is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<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-5535:Issue summary: Calling the OpenSSL API function SSL_select_next_proto with anempty supported client protocols buffer may cause a crash or memory contents tobe sent to the peer.Impact summary: A buffer overread can have a range of potential consequencessuch as unexpected application beahviour or a crash. In particular this issuecould result in up to 255 bytes of arbitrary private data from memory being sentto the peer leading to a loss of confidentiality. However, only applicationsthat directly call the SSL_select_next_proto function with a 0 length list ofsupported client protocols are affected by this issue. This would normally neverbe a valid scenario and is typically not under attacker control but may occur byaccident in the case of a configuration or programming error in the callingapplication.The OpenSSL API function SSL_select_next_proto is typically used by TLSapplications that support ALPN (Application Layer Protocol Negotiation) or NPN(Next Protocol Negotiation). NPN is older, was never standardised andis deprecated in favour of ALPN. We believe that ALPN is significantly morewidely deployed than NPN. The SSL_select_next_proto function accepts a list ofprotocols from the server and a list of protocols from the client and returnsthe first protocol that appears in the server list that also appears in theclient list. In the case of no overlap between the two lists it returns thefirst item in the client list. In either case it will signal whether an overlapbetween the two lists was found. In the case where SSL_select_next_proto iscalled with a zero length client list it fails to notice this condition andreturns the memory immediately following the client list pointer (and reportsthat there was no overlap in the lists).This function is typically called from a server side application callback forALPN or a client side application callback for NPN. In the case of ALPN the listof protocols supplied by the client is guaranteed by libssl to never be zero inlength. The list of server protocols comes from the application and should nevernormally be expected to be of zero length. In this case if theSSL_select_next_proto function has been called as expected (with the listsupplied by the client passed in the client/client_len parameters), then theapplication will not be vulnerable to this issue. If the application hasaccidentally been configured with a zero length server list, and hasaccidentally passed that zero length server list in the client/client_lenparameters, and has additionally failed to correctly handle a  no overlap response (which would normally result in a handshake failure in ALPN) then itwill be vulnerable to this problem.In the case of NPN, the protocol permits the client to opportunistically selecta protocol when there is no overlap. OpenSSL returns the first client protocolin the no overlap case in support of this. The list of client protocols comesfrom the application and should never normally be expected to be of zero length.However if the SSL_select_next_proto function is accidentally called with aclient_len of 0 then an invalid memory pointer will be returned instead. If theapplication uses this output as the opportunistic protocol then the loss ofconfidentiality will occur.This issue has been assessed as Low severity because applications are mostlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is notwidely used. It also requires an application configuration or programming error.Finally, this issue would not typically be under attacker control making activeexploitation unlikely.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.Due to the low severity of this issue we are not issuing new releases ofOpenSSL at this time. The fix will be included in the next releases when theybecome available.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="sgxsdk" release="12.u3.fos23" version="2.15.1">
					<filename>sgxsdk-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qe3" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-qe3-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-pce-logic" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-pce-logic-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-qe3-logic" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-qe3-logic-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-aesm-service" release="12.u3.fos23" version="2.15.1">
					<filename>sgx-aesm-service-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-epid" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-epid-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-le" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-le-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-pce" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-pce-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-ecdsa-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-ecdsa-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-epid-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-epid-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-launch-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-launch-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-pce-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-pce-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-aesm-quote-ex-plugin" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-aesm-quote-ex-plugin-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-epid-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-epid-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-epid-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-launch-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-launch-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-launch-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-quote-ex-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-quote-ex-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-quote-ex-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-uae-service" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-uae-service-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-enclave-common-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-enclave-common-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-enclave-common-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-urts" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-urts-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-default-qpl-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-default-qpl-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-dcap-pccs" release="12.u3.fos23" version="2.15.1">
					<filename>sgx-dcap-pccs-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-ql-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-ql-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-ql-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ae-qve" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ae-qve-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-dcap-quote-verify-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-dcap-quote-verify-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-pck-id-retrieval-tool" release="12.u3.fos23" version="2.15.1">
					<filename>sgx-pck-id-retrieval-tool-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ra-uefi-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-uefi-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ra-uefi-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ra-network-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-ra-network-devel" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-ra-network-devel-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="sgx-ra-service" release="12.u3.fos23" version="2.15.1">
					<filename>sgx-ra-service-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libsgx-headers" release="12.u3.fos23" version="2.15.1">
					<filename>libsgx-headers-2.15.1-12.u3.fos23.x86_64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2289</id>
		<title>An update for mysql is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21125" id="CVE-2024-21125" title="CVE-2024-21125" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21142" id="CVE-2024-21142" title="CVE-2024-21142" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21179" id="CVE-2024-21179" title="CVE-2024-21179" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21171" id="CVE-2024-21171" title="CVE-2024-21171" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21130" id="CVE-2024-21130" title="CVE-2024-21130" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21162" id="CVE-2024-21162" title="CVE-2024-21162" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21177" id="CVE-2024-21177" title="CVE-2024-21177" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20996" id="CVE-2024-20996" title="CVE-2024-20996" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21134" id="CVE-2024-21134" title="CVE-2024-21134" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21165" id="CVE-2024-21165" title="CVE-2024-21165" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21173" id="CVE-2024-21173" title="CVE-2024-21173" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21129" id="CVE-2024-21129" title="CVE-2024-21129" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21127" id="CVE-2024-21127" title="CVE-2024-21127" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21163" id="CVE-2024-21163" title="CVE-2024-21163" type="cve"/>
		</references>
		<description>CVE-2024-21125:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: FTS).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21142:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Security: Privileges).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21179:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21171:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21130:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21162:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21177:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 6.5 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-20996:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21134:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Connection Handling).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows low privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of MySQL Server. CVSS 3.1 Base Score 4.3 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21165:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Pluggable Auth).  Supported versions that are affected are 8.0.37 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21173:Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21129:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21127:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: DDL).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.9 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H).
CVE-2024-21163:Vulnerability in the MySQL Server product of Oracle MySQL (component: Server: Optimizer).  Supported versions that are affected are 8.0.37 and prior and  8.4.0 and prior. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server as well as  unauthorized update, insert or delete access to some of MySQL Server accessible data. CVSS 3.1 Base Score 5.5 (Integrity and Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:H).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="mysql" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-libs" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-libs-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-config" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-config-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-common" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-common-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-errmsg" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-errmsg-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-server" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-server-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-devel" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-devel-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-test" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-test-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="mysql-help" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-help-8.0.38-1.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-libs" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-libs-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-config" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-config-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-common" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-common-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-errmsg" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-errmsg-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-server" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-server-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-devel" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-devel-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-test" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-test-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="mysql-help" release="1.u2.fos23" version="8.0.38">
					<filename>mysql-help-8.0.38-1.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2290</id>
		<title>An update for nginx is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7347" id="CVE-2024-7347" title="CVE-2024-7347" type="cve"/>
		</references>
		<description>CVE-2024-7347:NGINX Open Source and NGINX Plus have a vulnerability in the ngx_http_mp4_module, which might allow an attacker to over-read NGINX worker memory resulting in its termination, using a specially crafted mp4 file. The issue only affects NGINX if it is built with the ngx_http_mp4_module and the mp4 directive is used in the configuration file. Additionally, the attack is possible only if an attacker can trigger the processing of a specially crafted mp4 file with the ngx_http_mp4_module.  Note: Software versions which have reached End of Technical Support (EoTS) are not evaluated.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="nginx" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-1.21.5-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="1" name="nginx-all-modules" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-all-modules-1.21.5-7.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="1" name="nginx-filesystem" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-filesystem-1.21.5-7.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-image-filter" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-perl" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-http-xslt-filter" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-mail" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-stream" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nginx-mod-devel" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="1" name="nginx-help" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-help-1.21.5-7.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nginx" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-1.21.5-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-image-filter" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-image-filter-1.21.5-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-perl" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-perl-1.21.5-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-http-xslt-filter" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-http-xslt-filter-1.21.5-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-mail" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-mail-1.21.5-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-stream" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-stream-1.21.5-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nginx-mod-devel" release="7.u4.fos23" version="1.21.5">
					<filename>nginx-mod-devel-1.21.5-7.u4.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2291</id>
		<title>An update for openresty-openssl111 is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<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 anempty supported client protocols buffer may cause a crash or memory contents tobe sent to the peer.Impact summary: A buffer overread can have a range of potential consequencessuch as unexpected application beahviour or a crash. In particular this issuecould result in up to 255 bytes of arbitrary private data from memory being sentto the peer leading to a loss of confidentiality. However, only applicationsthat directly call the SSL_select_next_proto function with a 0 length list ofsupported client protocols are affected by this issue. This would normally neverbe a valid scenario and is typically not under attacker control but may occur byaccident in the case of a configuration or programming error in the callingapplication.The OpenSSL API function SSL_select_next_proto is typically used by TLSapplications that support ALPN (Application Layer Protocol Negotiation) or NPN(Next Protocol Negotiation). NPN is older, was never standardised andis deprecated in favour of ALPN. We believe that ALPN is significantly morewidely deployed than NPN. The SSL_select_next_proto function accepts a list ofprotocols from the server and a list of protocols from the client and returnsthe first protocol that appears in the server list that also appears in theclient list. In the case of no overlap between the two lists it returns thefirst item in the client list. In either case it will signal whether an overlapbetween the two lists was found. In the case where SSL_select_next_proto iscalled with a zero length client list it fails to notice this condition andreturns the memory immediately following the client list pointer (and reportsthat there was no overlap in the lists).This function is typically called from a server side application callback forALPN or a client side application callback for NPN. In the case of ALPN the listof protocols supplied by the client is guaranteed by libssl to never be zero inlength. The list of server protocols comes from the application and should nevernormally be expected to be of zero length. In this case if theSSL_select_next_proto function has been called as expected (with the listsupplied by the client passed in the client/client_len parameters), then theapplication will not be vulnerable to this issue. If the application hasaccidentally been configured with a zero length server list, and hasaccidentally passed that zero length server list in the client/client_lenparameters, and has additionally failed to correctly handle a  no overlap response (which would normally result in a handshake failure in ALPN) then itwill be vulnerable to this problem.In the case of NPN, the protocol permits the client to opportunistically selecta protocol when there is no overlap. OpenSSL returns the first client protocolin the no overlap case in support of this. The list of client protocols comesfrom the application and should never normally be expected to be of zero length.However if the SSL_select_next_proto function is accidentally called with aclient_len of 0 then an invalid memory pointer will be returned instead. If theapplication uses this output as the opportunistic protocol then the loss ofconfidentiality will occur.This issue has been assessed as Low severity because applications are mostlikely to be vulnerable if they are using NPN instead of ALPN - but NPN is notwidely used. It also requires an application configuration or programming error.Finally, this issue would not typically be under attacker control making activeexploitation unlikely.The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.Due to the low severity of this issue we are not issuing new releases ofOpenSSL at this time. The fix will be included in the next releases when theybecome available.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="openresty-openssl111-asan" release="2.u6.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="openresty-openssl111-asan" release="2.u6.fos23" version="1.1.1h">
					<filename>openresty-openssl111-asan-1.1.1h-2.u6.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2292</id>
		<title>An update for openvpn is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5594" id="CVE-2024-5594" title="CVE-2024-5594" type="cve"/>
		</references>
		<description>CVE-2024-5594:OpenVPN incorrectly handled certain control channel messages with nonprintable characters. A remote attacker could possibly use this issue to cause OpenVPN to consume resources, or fill up log files with garbage, leading to a denial of service.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="openvpn" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-2.5.5-4.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="openvpn-devel" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-devel-2.5.5-4.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="openvpn-help" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-help-2.5.5-4.u2.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="openvpn" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-2.5.5-4.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="openvpn-devel" release="4.u2.fos23" version="2.5.5">
					<filename>openvpn-devel-2.5.5-4.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2293</id>
		<title>An update for orc is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40897" id="CVE-2024-40897" title="CVE-2024-40897" type="cve"/>
		</references>
		<description>CVE-2024-40897:Stack-based buffer overflow vulnerability exists in orcparse.c of ORC versions prior to 0.4.39. If a developer is tricked to process a specially crafted file with the affected ORC compiler, an arbitrary code may be executed on the developer s build environment. This may lead to compromise of developer machines or CI build environments.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="orc" release="3.u1.fos23" version="0.4.32">
					<filename>orc-0.4.32-3.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="orc-help" release="3.u1.fos23" version="0.4.32">
					<filename>orc-help-0.4.32-3.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="orc-devel" release="3.u1.fos23" version="0.4.32">
					<filename>orc-devel-0.4.32-3.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="orc-compiler" release="3.u1.fos23" version="0.4.32">
					<filename>orc-compiler-0.4.32-3.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="orc" release="3.u1.fos23" version="0.4.32">
					<filename>orc-0.4.32-3.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="orc-help" release="3.u1.fos23" version="0.4.32">
					<filename>orc-help-0.4.32-3.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="orc-devel" release="3.u1.fos23" version="0.4.32">
					<filename>orc-devel-0.4.32-3.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="orc-compiler" release="3.u1.fos23" version="0.4.32">
					<filename>orc-compiler-0.4.32-3.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2294</id>
		<title>An update for postgresql is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5868" id="CVE-2023-5868" title="CVE-2023-5868" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5869" id="CVE-2023-5869" title="CVE-2023-5869" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5870" id="CVE-2023-5870" title="CVE-2023-5870" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7348" id="CVE-2024-7348" title="CVE-2024-7348" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0985" id="CVE-2024-0985" title="CVE-2024-0985" type="cve"/>
		</references>
		<description>CVE-2023-5868:A memory disclosure vulnerability was found in PostgreSQL that allows remote users to access sensitive information by exploiting certain aggregate function calls with 'unknown'-type arguments. Handling 'unknown'-type values from string literals without type designation can disclose bytes, potentially revealing notable and confidential information. This issue exists due to excessive data output in aggregate function calls, enabling remote users to read some portion of system memory.
CVE-2023-5869:A flaw was found in PostgreSQL that allows authenticated database users to execute arbitrary code through missing overflow checks during SQL array value modification. This issue exists due to an integer overflow during array modification where a remote user can trigger the overflow by providing specially crafted data. This enables the execution of arbitrary code on the target system, allowing users to write arbitrary bytes to memory and extensively read the server's memory.
CVE-2023-5870:A flaw was found in PostgreSQL involving the pg_cancel_backend role that signals background workers, including the log
ical replication launcher, autovacuum workers, and the autovacuum launcher. Successful exploitation requires a non-core extension w
ith a less-resilient background worker and would affect that specific background worker only. This issue may allow a remote high pr
ivileged user to launch a denial of service (DoS) attack.
CVE-2024-7348:Time-of-check Time-of-use (TOCTOU) race condition in pg_dump in PostgreSQL allows an object creator to execute arbitrary SQL functions as the user running pg_dump, which is often a superuser. The attack involves replacing another relation type with a view or foreign table. The attack requires waiting for pg_dump to start, but winning the race condition is trivial if the attacker retains an open transaction. Versions before PostgreSQL 16.4, 15.8, 14.13, 13.16, and 12.20 are affected.
CVE-2024-0985:Late privilege drop in REFRESH MATERIALIZED VIEW CONCURRENTLY in PostgreSQL allows an object creator to execute arbitrary SQL functions as the command issuer. The command intends to run SQL functions as the owner of the materialized view, enabling safe refresh of untrusted materialized views. The victim is a superuser or member of one of the attacker's roles. The attack requires luring the victim into running REFRESH MATERIALIZED VIEW CONCURRENTLY on the attacker's materialized view. Versions before PostgreSQL 16.2, 15.6, 14.11, 13.14, and 12.18 are affected.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="postgresql" release="1.u3.fos23" version="13.16">
					<filename>postgresql-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-libs" release="1.u3.fos23" version="13.16">
					<filename>postgresql-private-libs-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-private-devel" release="1.u3.fos23" version="13.16">
					<filename>postgresql-private-devel-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server" release="1.u3.fos23" version="13.16">
					<filename>postgresql-server-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-docs" release="1.u3.fos23" version="13.16">
					<filename>postgresql-docs-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-contrib" release="1.u3.fos23" version="13.16">
					<filename>postgresql-contrib-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-server-devel" release="1.u3.fos23" version="13.16">
					<filename>postgresql-server-devel-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="postgresql-test-rpm-macros" release="1.u3.fos23" version="13.16">
					<filename>postgresql-test-rpm-macros-13.16-1.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-static" release="1.u3.fos23" version="13.16">
					<filename>postgresql-static-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plperl" release="1.u3.fos23" version="13.16">
					<filename>postgresql-plperl-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-plpython3" release="1.u3.fos23" version="13.16">
					<filename>postgresql-plpython3-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-pltcl" release="1.u3.fos23" version="13.16">
					<filename>postgresql-pltcl-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-test" release="1.u3.fos23" version="13.16">
					<filename>postgresql-test-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="postgresql-llvmjit" release="1.u3.fos23" version="13.16">
					<filename>postgresql-llvmjit-13.16-1.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql" release="1.u3.fos23" version="13.16">
					<filename>postgresql-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-libs" release="1.u3.fos23" version="13.16">
					<filename>postgresql-private-libs-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-private-devel" release="1.u3.fos23" version="13.16">
					<filename>postgresql-private-devel-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server" release="1.u3.fos23" version="13.16">
					<filename>postgresql-server-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-docs" release="1.u3.fos23" version="13.16">
					<filename>postgresql-docs-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-contrib" release="1.u3.fos23" version="13.16">
					<filename>postgresql-contrib-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-server-devel" release="1.u3.fos23" version="13.16">
					<filename>postgresql-server-devel-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-static" release="1.u3.fos23" version="13.16">
					<filename>postgresql-static-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plperl" release="1.u3.fos23" version="13.16">
					<filename>postgresql-plperl-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-plpython3" release="1.u3.fos23" version="13.16">
					<filename>postgresql-plpython3-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-pltcl" release="1.u3.fos23" version="13.16">
					<filename>postgresql-pltcl-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-test" release="1.u3.fos23" version="13.16">
					<filename>postgresql-test-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="postgresql-llvmjit" release="1.u3.fos23" version="13.16">
					<filename>postgresql-llvmjit-13.16-1.u3.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2295</id>
		<title>An update for python-pip is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45803" id="CVE-2023-45803" title="CVE-2023-45803" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37891" id="CVE-2024-37891" title="CVE-2024-37891" type="cve"/>
			<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-2024-3651" id="CVE-2024-3651" title="CVE-2024-3651" type="cve"/>
		</references>
		<description>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.
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.
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-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-pip" release="6.u4.fos23" version="21.3.1">
					<filename>python3-pip-21.3.1-6.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="python-pip-help" release="6.u4.fos23" version="21.3.1">
					<filename>python-pip-help-21.3.1-6.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="python-pip-wheel" release="6.u4.fos23" version="21.3.1">
					<filename>python-pip-wheel-21.3.1-6.u4.fos23.noarch.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2296</id>
		<title>An update for python-webob is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42353" id="CVE-2024-42353" title="CVE-2024-42353" type="cve"/>
		</references>
		<description>CVE-2024-42353:WebOb provides objects for HTTP requests and responses. When WebOb normalizes the HTTP Location header to include the request hostname, it does so by parsing the URL that the user is to be redirected to with Python s urlparse, and joining it to the base URL. `urlparse` however treats a `//` at the start of a string as a URI without a scheme, and then treats the next part as the hostname. `urljoin` will then use that hostname from the second part as the hostname replacing the original one from the request. This vulnerability is patched in WebOb version 1.8.8.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="noarch" epoch="0" name="python3-webob" release="3.u1.fos23" version="1.8.7">
					<filename>python3-webob-1.8.7-3.u1.fos23.noarch.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2297</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4032" id="CVE-2024-4032" title="CVE-2024-4032" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0397" id="CVE-2024-0397" title="CVE-2024-0397" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7592" id="CVE-2024-7592" title="CVE-2024-7592" type="cve"/>
		</references>
		<description>CVE-2024-4032:The “ipaddress” module contained incorrect information about whether certain IPv4 and IPv6 addresses were designated as “globally reachable” or “private”. This affected the is_private and is_global properties of the ipaddress.IPv4Address, ipaddress.IPv4Network, ipaddress.IPv6Address, and ipaddress.IPv6Network classes, where values wouldn’t be returned in accordance with the latest information from the IANA Special-Purpose Address Registries.
CPython 3.12.4 and 3.13.0a6 contain updated information from these registries and thus have the intended behavior.
CVE-2024-0397:A defect was discovered in the Python “ssl” module where there is a memoryrace condition with the ssl.SSLContext methods “cert_store_stats()” and“get_ca_certs()”. The race condition can be triggered if the methods arecalled at the same time as certificates are loaded into the SSLContext,such as during the TLS handshake with a certificate directory configured.This issue is fixed in CPython 3.10.14, 3.11.9, 3.12.3, and 3.13.0a5.
CVE-2024-7592:There is a LOW severity vulnerability affecting CPython, specifically the
'http.cookies' standard library module.
When parsing cookies that contained backslashes for quoted characters in
the cookie value, the parser would use an algorithm with quadratic
complexity, resulting in excess CPU resources being used while parsing the
value.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="python3" release="29.u12.fos23" version="3.9.9">
					<filename>python3-3.9.9-29.u12.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="29.u12.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-29.u12.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="29.u12.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-29.u12.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="29.u12.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-29.u12.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="29.u12.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-29.u12.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="29.u12.fos23" version="3.9.9">
					<filename>python3-3.9.9-29.u12.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="29.u12.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-29.u12.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="29.u12.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-29.u12.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="29.u12.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-29.u12.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2298</id>
		<title>An update for qemu is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7409" id="CVE-2024-7409" title="CVE-2024-7409" type="cve"/>
		</references>
		<description>CVE-2024-7409:A flaw was found in the QEMU NBD Server. This vulnerability allows a denial of service (DoS) attack via improper synchronization during socket closure when a client keeps a socket open as the server is taken offline.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="10" name="qemu" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-guest-agent" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="10" name="qemu-help" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-help-6.2.0-97.u19.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-img" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-rbd" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-ssh" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-iscsi" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-block-curl" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-hw-usb-host" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-seabios" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-seabios-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-aarch64" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-arm" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-x86_64" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="10" name="qemu-system-riscv" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-97.u19.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-guest-agent" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-guest-agent-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-img" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-img-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-rbd" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-rbd-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-ssh" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-ssh-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-iscsi" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-iscsi-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-block-curl" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-block-curl-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-hw-usb-host" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-hw-usb-host-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-aarch64" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-aarch64-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-arm" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-arm-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-x86_64" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-x86_64-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="10" name="qemu-system-riscv" release="97.u19.fos23" version="6.2.0">
					<filename>qemu-system-riscv-6.2.0-97.u19.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2299</id>
		<title>An update for redis5 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32626" id="CVE-2021-32626" title="CVE-2021-32626" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32627" id="CVE-2021-32627" title="CVE-2021-32627" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32628" id="CVE-2021-32628" title="CVE-2021-32628" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32762" id="CVE-2021-32762" title="CVE-2021-32762" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-41099" id="CVE-2021-41099" title="CVE-2021-41099" type="cve"/>
		</references>
		<description>CVE-2021-32626:Redis is an open source, in-memory database that persists on disk. In affected versions specially crafted Lua scripts executing in Redis can cause the heap-based Lua stack to be overflowed, due to incomplete checks for this condition. This can result with heap corruption and potentially remote code execution. This problem exists in all versions of Redis with Lua scripting support, starting from 2.6. The problem is fixed in versions 6.2.6, 6.0.16 and 5.0.14. For users unable to update an additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from executing Lua scripts. This can be done using ACL to restrict EVAL and EVALSHA commands.
CVE-2021-32627:Redis is an open source, in-memory database that persists on disk. In affected versions an integer overflow bug in Redis can be exploited to corrupt the heap and potentially result with remote code execution. The vulnerability involves changing the default proto-max-bulk-len and client-query-buffer-limit configuration parameters to very large values and constructing specially crafted very large stream elements. The problem is fixed in Redis 6.2.6, 6.0.16 and 5.0.14. For users unable to upgrade an additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the proto-max-bulk-len configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.
CVE-2021-32628:Redis is an open source, in-memory database that persists on disk. An integer overflow bug in the ziplist data structure used by all versions of Redis can be exploited to corrupt the heap and potentially result with remote code execution. The vulnerability involves modifying the default ziplist configuration parameters (hash-max-ziplist-entries, hash-max-ziplist-value, zset-max-ziplist-entries or zset-max-ziplist-value) to a very large value, and then constructing specially crafted commands to create very large ziplists. The problem is fixed in Redis versions 6.2.6, 6.0.16, 5.0.14. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the above configuration parameters. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.
CVE-2021-32762:Redis is an open source, in-memory database that persists on disk. The redis-cli command line tool and redis-sentinel service may be vulnerable to integer overflow when parsing specially crafted large multi-bulk network replies. This is a result of a vulnerability in the underlying hiredis library which does not perform an overflow check before calling the calloc() heap allocation function. This issue only impacts systems with heap allocators that do not perform their own overflow checks. Most modern systems do and are therefore not likely to be affected. Furthermore, by default redis-sentinel uses the jemalloc allocator which is also not vulnerable. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14.
CVE-2021-41099:Redis is an open source, in-memory database that persists on disk. An integer overflow bug in the underlying string library can be used to corrupt the heap and potentially result with denial of service or remote code execution. The vulnerability involves changing the default proto-max-bulk-len configuration parameter to a very large value and constructing specially crafted network payloads or commands. The problem is fixed in Redis versions 6.2.6, 6.0.16 and 5.0.14. An additional workaround to mitigate the problem without patching the redis-server executable is to prevent users from modifying the proto-max-bulk-len configuration parameter. This can be done using ACL to restrict unprivileged users from using the CONFIG SET command.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="redis5" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="redis5-devel" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="redis5-doc" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-doc-5.0.7-6.u8.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="redis5" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-5.0.7-6.u8.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="redis5-devel" release="6.u8.fos23" version="5.0.7">
					<filename>redis5-devel-5.0.7-6.u8.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2300</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41946" id="CVE-2024-41946" title="CVE-2024-41946" type="cve"/>
		</references>
		<description>CVE-2024-41946:REXML is an XML toolkit for Ruby. The REXML gem 3.3.2 has a DoS vulnerability when it parses an XML that has many entity expansions with SAX2 or pull parser API. The REXML gem 3.3.3 or later include the patch to fix the vulnerability.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="ruby" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-3.0.3-137.u11.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-137.u11.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="137.u11.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="137.u11.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="137.u11.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="137.u11.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="137.u11.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="137.u11.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-137.u11.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="137.u11.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="137.u11.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-137.u11.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="137.u11.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-137.u11.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="137.u11.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="137.u11.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-137.u11.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="137.u11.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-137.u11.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="137.u11.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="137.u11.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="137.u11.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="137.u11.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-137.u11.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-3.0.3-137.u11.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="137.u11.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-137.u11.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="137.u11.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-137.u11.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="137.u11.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-137.u11.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="137.u11.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-137.u11.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="137.u11.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-137.u11.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="137.u11.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-137.u11.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2301</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43167" id="CVE-2024-43167" title="CVE-2024-43167" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43168" id="CVE-2024-43168" title="CVE-2024-43168" type="cve"/>
		</references>
		<description>CVE-2024-43167:A NULL pointer dereference flaw was found in the ub_ctx_set_fwd function in Unbound. This issue could allow an attacker who can invoke specific sequences of API calls to cause a segmentation fault. When certain API functions such as ub_ctx_set_fwd and ub_ctx_resolvconf are called in a particular order, the program attempts to read from a NULL pointer, leading to a crash. This issue can result in a denial of service by causing the application to terminate unexpectedly.
CVE-2024-43168:A heap-buffer-overflow flaw was found in the cfg_mark_ports function within Unbound's config_file.c, which can lead to memory corruption. This issue could allow an attacker with local access to provide specially crafted input, potentially causing the application to crash or allowing arbitrary code execution. This could result in a denial of service or unauthorized actions on the system.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="unbound" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-1.13.2-12.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-libs" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-12.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-devel" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-12.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unbound" release="12.u5.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-12.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-help" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-12.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="unbound" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-1.13.2-12.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-libs" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-12.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-devel" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-12.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unbound" release="12.u5.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-12.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-help" release="12.u5.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-12.u5.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2302</id>
		<title>An update for wget is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-09-10"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38428" id="CVE-2024-38428" title="CVE-2024-38428" type="cve"/>
		</references>
		<description>CVE-2024-38428:url.c in GNU Wget through 1.24.5 mishandles semicolons in the userinfo subcomponent of a URI, and thus there may be insecure behavior in which data that was supposed to be in the userinfo subcomponent is misinterpreted to be part of the host subcomponent.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="wget" release="5.u2.fos23" version="1.21.2">
					<filename>wget-1.21.2-5.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="wget-help" release="5.u2.fos23" version="1.21.2">
					<filename>wget-help-1.21.2-5.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="wget" release="5.u2.fos23" version="1.21.2">
					<filename>wget-1.21.2-5.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="wget-help" release="5.u2.fos23" version="1.21.2">
					<filename>wget-help-1.21.2-5.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2303</id>
		<title>An update for 389-ds-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1949" id="CVE-2022-1949" title="CVE-2022-1949" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5953" id="CVE-2024-5953" title="CVE-2024-5953" type="cve"/>
		</references>
		<description>CVE-2022-1949:An access control bypass vulnerability found in 389-ds-base. That mishandling of the filter that would yield incorrect results, but as that has progressed, can be determined that it actually is an access control bypass. This may allow any remote unauthenticated user to issue a filter that allows searching for database items they do not have access to, including but not limited to potentially userPassword hashes and other sensitive data.
CVE-2024-5953:A denial of service vulnerability was found in the 389-ds-base LDAP server. This issue may allow an authenticated user to cause a server denial of service while attempting to log in with a user with a malformed hash in their password.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="389-ds-base" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-legacy-tools" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-devel" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-snmp" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="python3-lib389" release="7.u4.fos23" version="1.4.3.36">
					<filename>python3-lib389-1.4.3.36-7.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="cockpit-389-ds" release="7.u4.fos23" version="1.4.3.36">
					<filename>cockpit-389-ds-1.4.3.36-7.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="389-ds-base-help" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-7.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-legacy-tools" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-legacy-tools-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-devel" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-devel-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-snmp" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-snmp-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="389-ds-base-help" release="7.u4.fos23" version="1.4.3.36">
					<filename>389-ds-base-help-1.4.3.36-7.u4.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2304</id>
		<title>An update for OpenIPMI is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42934" id="CVE-2024-42934" title="CVE-2024-42934" type="cve"/>
		</references>
		<description>CVE-2024-42934:OpenIPMI before 2.0.36 has an out-of-bounds array access (for authentication type) in the ipmi_sim simulator, resulting in denial of service or (with very low probability) authentication bypass or code execution.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="OpenIPMI" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-2.0.32-4.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="OpenIPMI-perl" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-perl-2.0.32-4.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-openipmi" release="4.u2.fos23" version="2.0.32">
					<filename>python3-openipmi-2.0.32-4.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="OpenIPMI-devel" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-devel-2.0.32-4.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="OpenIPMI-help" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-help-2.0.32-4.u2.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="OpenIPMI" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-2.0.32-4.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="OpenIPMI-perl" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-perl-2.0.32-4.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-openipmi" release="4.u2.fos23" version="2.0.32">
					<filename>python3-openipmi-2.0.32-4.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="OpenIPMI-devel" release="4.u2.fos23" version="2.0.32">
					<filename>OpenIPMI-devel-2.0.32-4.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2305</id>
		<title>An update for assimp is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45679" id="CVE-2024-45679" title="CVE-2024-45679" type="cve"/>
		</references>
		<description>CVE-2024-45679:Heap-based buffer overflow vulnerability in Assimp versions prior to 5.4.3 allows a local attacker to execute arbitrary code by importing a specially crafted file into the product.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="assimp" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-5.2.4-3.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="assimp-devel" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-devel-5.2.4-3.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="python3-assimp" release="3.u2.fos23" version="5.2.4">
					<filename>python3-assimp-5.2.4-3.u2.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="assimp-help" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-help-5.2.4-3.u2.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="assimp" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-5.2.4-3.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="assimp-devel" release="3.u2.fos23" version="5.2.4">
					<filename>assimp-devel-5.2.4-3.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2306</id>
		<title>An update for cups-filters is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47076" id="CVE-2024-47076" title="CVE-2024-47076" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47175" id="CVE-2024-47175" title="CVE-2024-47175" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47176" id="CVE-2024-47176" title="CVE-2024-47176" type="cve"/>
		</references>
		<description>CVE-2024-47076:CUPS is a standards-based, open-source printing system, and `libcupsfilters` contains the code of the filters of the former `cups-filters` package as library functions to be used for the data format conversion tasks needed in Printer Applications. The `cfGetPrinterAttributes5` function in `libcupsfilters` does not sanitize IPP attributes returned from an IPP server. When these IPP attributes are used, for instance, to generate a PPD file, this can lead to attacker controlled data to be provided to the rest of the CUPS system.
CVE-2024-47175:CUPS is a standards-based, open-source printing system, and `libppd` can be used for legacy PPD file support. The `libppd` function `ppdCreatePPDFromIPP2` does not sanitize IPP attributes when creating the PPD buffer. When used in combination with other functions such as `cfGetPrinterAttributes5`, can result in user controlled input and ultimately code execution via Foomatic. This vulnerability can be part of an exploit chain leading to remote code execution (RCE), as described in CVE-2024-47176.
CVE-2024-47176:CUPS is a standards-based, open-source printing system, and `cups-browsed` contains network printing functionality including, but not limited to, auto-discovering print services and shared printers. `cups-browsed` binds to `INADDR_ANY:631`, causing it to trust any packet from any source, and can cause the `Get-Printer-Attributes` IPP request to an attacker controlled URL. When combined with other vulnerabilities, such as CVE-2024-47076, CVE-2024-47175, and CVE-2024-47177, an attacker can execute arbitrary commands remotely on the target machine without authentication when a malicious printer is printed to.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="cups-filters" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-1.28.9-4.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="cups-filters-devel" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-4.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="cups-filters-help" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-help-1.28.9-4.u2.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-1.28.9-4.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="cups-filters-devel" release="4.u2.fos23" version="1.28.9">
					<filename>cups-filters-devel-1.28.9-4.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2307</id>
		<title>An update for curl is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8096" id="CVE-2024-8096" title="CVE-2024-8096" type="cve"/>
		</references>
		<description>CVE-2024-8096:When curl is told to use the Certificate Status Request TLS extension, often referred to as OCSP stapling, to verify that the server certificate is valid, it might fail to detect some OCSP problems and instead wrongly consider the response as fine.  If the returned status reports another error than 'revoked' (like for example 'unauthorized') it is not treated as a bad certficate.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="curl" release="32.u18.fos23" version="7.79.1">
					<filename>curl-7.79.1-32.u18.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl" release="32.u18.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-32.u18.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libcurl-devel" release="32.u18.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-32.u18.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="curl-help" release="32.u18.fos23" version="7.79.1">
					<filename>curl-help-7.79.1-32.u18.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="curl" release="32.u18.fos23" version="7.79.1">
					<filename>curl-7.79.1-32.u18.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl" release="32.u18.fos23" version="7.79.1">
					<filename>libcurl-7.79.1-32.u18.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libcurl-devel" release="32.u18.fos23" version="7.79.1">
					<filename>libcurl-devel-7.79.1-32.u18.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2308</id>
		<title>An update for edk2 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<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-2022-0778" id="CVE-2022-0778" title="CVE-2022-0778" type="cve"/>
		</references>
		<description>CVE-2021-3712:ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL'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-2022-0778:The BN_mod_sqrt() function, which computes a modular square root, contains a bug that can cause it to loop forever for non-prime moduli. Internally this function is used when parsing certificates that contain elliptic curve public keys in compressed form or explicit elliptic curve parameters with a base point encoded in compressed form. It is possible to trigger the infinite loop by crafting a certificate that has invalid explicit curve parameters. Since certificate parsing happens prior to verification of the certificate signature, any process that parses an externally supplied certificate may thus be subject to a denial of service attack. The infinite loop can also be reached when parsing crafted private keys as they can contain explicit elliptic curve parameters. Thus vulnerable situations include: - TLS clients consuming server certificates - TLS servers consuming client certificates - Hosting providers taking certificates or private keys from customers - Certificate authorities parsing certification requests from subscribers - Anything else which parses ASN.1 elliptic curve parameters Also any other applications that use the BN_mod_sqrt() where the attacker can control the parameter values are vulnerable to this DoS issue. In the OpenSSL 1.0.2 version the public key is not parsed during initial parsing of the certificate which makes it slightly harder to trigger the infinite loop. However any operation which requires the public key from the certificate will trigger the infinite loop. In particular the attacker can use a self-signed certificate to trigger the loop during verification of the certificate signature. This issue affects OpenSSL versions 1.0.2, 1.1.1 and 3.0. It was addressed in the releases of 1.1.1n and 3.0.2 on the 15th March 2022. Fixed in OpenSSL 3.0.2 (Affected 3.0.0,3.0.1). Fixed in OpenSSL 1.1.1n (Affected 1.1.1-1.1.1m). Fixed in OpenSSL 1.0.2zd (Affected 1.0.2-1.0.2zc).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="edk2-devel" release="20.u9.fos23" version="202011">
					<filename>edk2-devel-202011-20.u9.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="python3-edk2-devel" release="20.u9.fos23" version="202011">
					<filename>python3-edk2-devel-202011-20.u9.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="edk2-help" release="20.u9.fos23" version="202011">
					<filename>edk2-help-202011-20.u9.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="edk2-ovmf" release="20.u9.fos23" version="202011">
					<filename>edk2-ovmf-202011-20.u9.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="edk2-devel" release="20.u9.fos23" version="202011">
					<filename>edk2-devel-202011-20.u9.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2309</id>
		<title>An update for ffmpeg is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35965" id="CVE-2020-35965" title="CVE-2020-35965" type="cve"/>
		</references>
		<description>CVE-2020-35965:decode_frame in libavcodec/exr.c in FFmpeg 4.3.1 has an out-of-bounds write because of errors in calculations of when to perform memset zero operations.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="ffmpeg" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-4.2.4-18.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-libs" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-18.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libavdevice" release="18.u2.fos23" version="4.2.4">
					<filename>libavdevice-4.2.4-18.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="ffmpeg-devel" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-18.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-4.2.4-18.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-libs" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-libs-4.2.4-18.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libavdevice" release="18.u2.fos23" version="4.2.4">
					<filename>libavdevice-4.2.4-18.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ffmpeg-devel" release="18.u2.fos23" version="4.2.4">
					<filename>ffmpeg-devel-4.2.4-18.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2310</id>
		<title>An update for fop is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28168" id="CVE-2024-28168" title="CVE-2024-28168" type="cve"/>
		</references>
		<description>CVE-2024-28168:Improper Restriction of XML External Entity Reference ('XXE') vulnerability in Apache XML Graphics FOP.
This issue affects Apache XML Graphics FOP: 2.9.
Users are recommended to upgrade to version 2.10, which fixes the issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="noarch" epoch="0" name="fop" release="9.u2.fos23" version="2.2">
					<filename>fop-2.2-9.u2.fos23.noarch.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2311</id>
		<title>An update for ghostscript is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33871" id="CVE-2024-33871" title="CVE-2024-33871" type="cve"/>
		</references>
		<description>CVE-2024-33871:An issue was discovered in Artifex Ghostscript before 10.03.1. contrib/opvp/gdevopvp.c allows arbitrary code execution via a custom Driver library, exploitable via a crafted PostScript document. This occurs because the Driver parameter for opvp (and oprp) devices can have an arbitrary name for a dynamic library; this library is then loaded.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="ghostscript" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-11.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-devel" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-11.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="ghostscript-help" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-help-9.55.0-11.u8.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="ghostscript-tools-dvipdf" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-11.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-9.55.0-11.u8.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-devel" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-devel-9.55.0-11.u8.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ghostscript-tools-dvipdf" release="11.u8.fos23" version="9.55.0">
					<filename>ghostscript-tools-dvipdf-9.55.0-11.u8.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2312</id>
		<title>An update for gstreamer1-plugins-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4453" id="CVE-2024-4453" title="CVE-2024-4453" type="cve"/>
		</references>
		<description>CVE-2024-4453:GStreamer EXIF Metadata Parsing Integer Overflow Remote Code Execution Vulnerability. This vulnerability allows remote attackers to execute arbitrary code on affected installations of GStreamer. Interaction with this library is required to exploit this vulnerability but attack vectors may vary depending on the implementation.
The specific flaw exists within the parsing of EXIF metadata. The issue results from the lack of proper validation of user-supplied data, which can result in an integer overflow before allocating a buffer. An attacker can leverage this vulnerability to execute code in the context of the current process.
. Was ZDI-CAN-23896.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-5.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="gstreamer1-plugins-base-devel" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-5.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="gstreamer1-plugins-base-help" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-help-1.18.4-5.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-1.18.4-5.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="gstreamer1-plugins-base-devel" release="5.u3.fos23" version="1.18.4">
					<filename>gstreamer1-plugins-base-devel-1.18.4-5.u3.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2313</id>
		<title>An update for java-1.8.0-openjdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21208" id="CVE-2024-21208" title="CVE-2024-21208" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"/>
		</references>
		<description>CVE-2024-21208:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Networking).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. This vulnerability does not apply to Java deployments, typically in servers, that load and run only trusted code (e.g., code installed by an administrator). CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21210:Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
CVE-2024-21217:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21235:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-javadoc-1.8.0.422.b05-0.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="1" name="java-1.8.0-openjdk-javadoc-zip" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.422.b05-0.u4.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-headless-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-devel-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-demo-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-src-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.u4.fos23" version="1.8.0.422.b05">
					<filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.u4.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2314</id>
		<title>An update for java-11-openjdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"/>
		</references>
		<description>CVE-2024-21210:Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
CVE-2024-21217:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21235:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="java-11-openjdk" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-headless-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-devel-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-jmods-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-demo-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-src-slowdebug" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-11-openjdk-javadoc-zip" release="0.u1.fos23" version="11.0.24.8">
					<filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2315</id>
		<title>An update for java-17-openjdk is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21210" id="CVE-2024-21210" title="CVE-2024-21210" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21217" id="CVE-2024-21217" title="CVE-2024-21217" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21235" id="CVE-2024-21235" title="CVE-2024-21235" type="cve"/>
		</references>
		<description>CVE-2024-21210:Vulnerability in Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4 and  23. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N).
CVE-2024-21217:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Serialization).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23; Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23; Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in unauthorized ability to cause a partial denial of service (partial DOS) of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 3.7 (Availability impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).
CVE-2024-21235:Vulnerability in the Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition product of Oracle Java SE (component: Hotspot).  Supported versions that are affected are Oracle Java SE: 8u421, 8u421-perf, 11.0.24, 17.0.12, 21.0.4, 23;   Oracle GraalVM for JDK: 17.0.12, 21.0.4, 23;   Oracle GraalVM Enterprise Edition: 20.3.15 and  21.3.11. Difficult to exploit vulnerability allows unauthenticated attacker with network access via multiple protocols to compromise Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition.  Successful attacks of this vulnerability can result in  unauthorized update, insert or delete access to some of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data as well as  unauthorized read access to a subset of Oracle Java SE, Oracle GraalVM for JDK, Oracle GraalVM Enterprise Edition accessible data. Note: This vulnerability can be exploited by using APIs in the specified Component, e.g., through a web service which supplies data to the APIs. This vulnerability also applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed Java applets, that load and run untrusted code (e.g., code that comes from the internet) and rely on the Java sandbox for security. CVSS 3.1 Base Score 4.8 (Confidentiality and Integrity impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="java-17-openjdk" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-headless-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-devel-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-jmods-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-demo-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-src-slowdebug" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="java-17-openjdk-javadoc-zip" release="0.u6.fos23" version="17.0.12.7">
					<filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.u6.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2316</id>
		<title>An update for jbig2dec is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46361" id="CVE-2023-46361" title="CVE-2023-46361" type="cve"/>
		</references>
		<description>CVE-2023-46361:Artifex Software jbig2dec v0.20 was discovered to contain a SEGV vulnerability via jbig2_error at /jbig2dec/jbig2.c.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="jbig2dec" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-0.19-5.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="jbig2dec-devel" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-devel-0.19-5.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="jbig2dec-help" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-help-0.19-5.u1.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="jbig2dec" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-0.19-5.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="jbig2dec-devel" release="5.u1.fos23" version="0.19">
					<filename>jbig2dec-devel-0.19-5.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2317</id>
		<title>An update for json-lib is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47855" id="CVE-2024-47855" title="CVE-2024-47855" type="cve"/>
		</references>
		<description>CVE-2024-47855:util/JSONTokener.java in JSON-lib before 3.1.0 mishandles an unbalanced comment string.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="noarch" epoch="0" name="json-lib" release="23.u1.fos23" version="2.4">
					<filename>json-lib-2.4-23.u1.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="jenkins-json-lib" release="23.u1.fos23" version="2.4">
					<filename>jenkins-json-lib-2.4-23.u1.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="json-lib-help" release="23.u1.fos23" version="2.4">
					<filename>json-lib-help-2.4-23.u1.fos23.noarch.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2318</id>
		<title>An update for kernel is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52742" id="CVE-2023-52742" title="CVE-2023-52742" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38565" id="CVE-2024-38565" title="CVE-2024-38565" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39490" id="CVE-2024-39490" title="CVE-2024-39490" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41016" id="CVE-2024-41016" title="CVE-2024-41016" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42121" id="CVE-2024-42121" title="CVE-2024-42121" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41098" id="CVE-2024-41098" title="CVE-2024-41098" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52748" id="CVE-2023-52748" title="CVE-2023-52748" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42309" id="CVE-2024-42309" title="CVE-2024-42309" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43828" id="CVE-2024-43828" title="CVE-2024-43828" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41068" id="CVE-2024-41068" title="CVE-2024-41068" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42122" id="CVE-2024-42122" title="CVE-2024-42122" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42322" id="CVE-2024-42322" title="CVE-2024-42322" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42290" id="CVE-2024-42290" title="CVE-2024-42290" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43824" id="CVE-2024-43824" title="CVE-2024-43824" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42313" id="CVE-2024-42313" title="CVE-2024-42313" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43831" id="CVE-2024-43831" title="CVE-2024-43831" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43860" id="CVE-2024-43860" title="CVE-2024-43860" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43819" id="CVE-2024-43819" title="CVE-2024-43819" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42126" id="CVE-2024-42126" title="CVE-2024-42126" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43823" id="CVE-2024-43823" title="CVE-2024-43823" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42281" id="CVE-2024-42281" title="CVE-2024-42281" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36946" id="CVE-2024-36946" title="CVE-2024-36946" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38613" id="CVE-2024-38613" title="CVE-2024-38613" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40901" id="CVE-2024-40901" title="CVE-2024-40901" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41008" id="CVE-2024-41008" title="CVE-2024-41008" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52898" id="CVE-2023-52898" title="CVE-2023-52898" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48899" id="CVE-2022-48899" title="CVE-2022-48899" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43879" id="CVE-2024-43879" title="CVE-2024-43879" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48896" id="CVE-2022-48896" title="CVE-2022-48896" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42297" id="CVE-2024-42297" title="CVE-2024-42297" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43866" id="CVE-2024-43866" title="CVE-2024-43866" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42280" id="CVE-2024-42280" title="CVE-2024-42280" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52901" id="CVE-2023-52901" title="CVE-2023-52901" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52903" id="CVE-2023-52903" title="CVE-2023-52903" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43882" id="CVE-2024-43882" title="CVE-2024-43882" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43849" id="CVE-2024-43849" title="CVE-2024-43849" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42312" id="CVE-2024-42312" title="CVE-2024-42312" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48873" id="CVE-2022-48873" title="CVE-2022-48873" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52893" id="CVE-2023-52893" title="CVE-2023-52893" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42120" id="CVE-2024-42120" title="CVE-2024-42120" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48935" id="CVE-2022-48935" title="CVE-2022-48935" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42308" id="CVE-2024-42308" title="CVE-2024-42308" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42153" id="CVE-2024-42153" title="CVE-2024-42153" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48898" id="CVE-2022-48898" title="CVE-2022-48898" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42230" id="CVE-2024-42230" title="CVE-2024-42230" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42265" id="CVE-2024-42265" title="CVE-2024-42265" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52896" id="CVE-2023-52896" title="CVE-2023-52896" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43883" id="CVE-2024-43883" title="CVE-2024-43883" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48920" id="CVE-2022-48920" title="CVE-2022-48920" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48871" id="CVE-2022-48871" title="CVE-2022-48871" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48877" id="CVE-2022-48877" title="CVE-2022-48877" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42267" id="CVE-2024-42267" title="CVE-2024-42267" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43890" id="CVE-2024-43890" title="CVE-2024-43890" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43854" id="CVE-2024-43854" title="CVE-2024-43854" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42299" id="CVE-2024-42299" title="CVE-2024-42299" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52880" id="CVE-2023-52880" title="CVE-2023-52880" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48811" id="CVE-2022-48811" title="CVE-2022-48811" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42288" id="CVE-2024-42288" title="CVE-2024-42288" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43908" id="CVE-2024-43908" title="CVE-2024-43908" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42286" id="CVE-2024-42286" title="CVE-2024-42286" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52889" id="CVE-2023-52889" title="CVE-2023-52889" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43884" id="CVE-2024-43884" title="CVE-2024-43884" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43907" id="CVE-2024-43907" title="CVE-2024-43907" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44938" id="CVE-2024-44938" title="CVE-2024-44938" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43892" id="CVE-2024-43892" title="CVE-2024-43892" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44934" id="CVE-2024-44934" title="CVE-2024-44934" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43893" id="CVE-2024-43893" title="CVE-2024-43893" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52906" id="CVE-2023-52906" title="CVE-2023-52906" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48872" id="CVE-2022-48872" title="CVE-2022-48872" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43905" id="CVE-2024-43905" title="CVE-2024-43905" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52899" id="CVE-2023-52899" title="CVE-2023-52899" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43889" id="CVE-2024-43889" title="CVE-2024-43889" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41060" id="CVE-2024-41060" title="CVE-2024-41060" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41082" id="CVE-2024-41082" title="CVE-2024-41082" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48879" id="CVE-2022-48879" title="CVE-2022-48879" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43856" id="CVE-2024-43856" title="CVE-2024-43856" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44944" id="CVE-2024-44944" title="CVE-2024-44944" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43898" id="CVE-2024-43898" title="CVE-2024-43898" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48891" id="CVE-2022-48891" title="CVE-2022-48891" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44946" id="CVE-2024-44946" title="CVE-2024-44946" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44942" id="CVE-2024-44942" title="CVE-2024-44942" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42295" id="CVE-2024-42295" title="CVE-2024-42295" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43834" id="CVE-2024-43834" title="CVE-2024-43834" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42259" id="CVE-2024-42259" title="CVE-2024-42259" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45896" id="CVE-2023-45896" title="CVE-2023-45896" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43902" id="CVE-2024-43902" title="CVE-2024-43902" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44947" id="CVE-2024-44947" title="CVE-2024-44947" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48902" id="CVE-2022-48902" title="CVE-2022-48902" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48901" id="CVE-2022-48901" title="CVE-2022-48901" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43914" id="CVE-2024-43914" title="CVE-2024-43914" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52907" id="CVE-2023-52907" title="CVE-2023-52907" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43899" id="CVE-2024-43899" title="CVE-2024-43899" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42276" id="CVE-2024-42276" title="CVE-2024-42276" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42311" id="CVE-2024-42311" title="CVE-2024-42311" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44960" id="CVE-2024-44960" title="CVE-2024-44960" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44971" id="CVE-2024-44971" title="CVE-2024-44971" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52916" id="CVE-2023-52916" title="CVE-2023-52916" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43829" id="CVE-2024-43829" title="CVE-2024-43829" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36934" id="CVE-2024-36934" title="CVE-2024-36934" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48887" id="CVE-2022-48887" title="CVE-2022-48887" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44948" id="CVE-2024-44948" title="CVE-2024-44948" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44988" id="CVE-2024-44988" title="CVE-2024-44988" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44986" id="CVE-2024-44986" title="CVE-2024-44986" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44987" id="CVE-2024-44987" title="CVE-2024-44987" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52915" id="CVE-2023-52915" title="CVE-2023-52915" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52894" id="CVE-2023-52894" title="CVE-2023-52894" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48828" id="CVE-2022-48828" title="CVE-2022-48828" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52900" id="CVE-2023-52900" title="CVE-2023-52900" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42104" id="CVE-2024-42104" title="CVE-2024-42104" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41059" id="CVE-2024-41059" title="CVE-2024-41059" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42292" id="CVE-2024-42292" title="CVE-2024-42292" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41017" id="CVE-2024-41017" title="CVE-2024-41017" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42119" id="CVE-2024-42119" title="CVE-2024-42119" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36915" id="CVE-2024-36915" title="CVE-2024-36915" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44999" id="CVE-2024-44999" title="CVE-2024-44999" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44974" id="CVE-2024-44974" title="CVE-2024-44974" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45003" id="CVE-2024-45003" title="CVE-2024-45003" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46745" id="CVE-2024-46745" title="CVE-2024-46745" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45028" id="CVE-2024-45028" title="CVE-2024-45028" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46723" id="CVE-2024-46723" title="CVE-2024-46723" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36270" id="CVE-2024-36270" title="CVE-2024-36270" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46747" id="CVE-2024-46747" title="CVE-2024-46747" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44995" id="CVE-2024-44995" title="CVE-2024-44995" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46714" id="CVE-2024-46714" title="CVE-2024-46714" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46731" id="CVE-2024-46731" title="CVE-2024-46731" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44965" id="CVE-2024-44965" title="CVE-2024-44965" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46787" id="CVE-2024-46787" title="CVE-2024-46787" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46751" id="CVE-2024-46751" title="CVE-2024-46751" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46752" id="CVE-2024-46752" title="CVE-2024-46752" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46733" id="CVE-2024-46733" title="CVE-2024-46733" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46744" id="CVE-2024-46744" title="CVE-2024-46744" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48721" id="CVE-2022-48721" title="CVE-2022-48721" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37021" id="CVE-2024-37021" title="CVE-2024-37021" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47622" id="CVE-2021-47622" title="CVE-2021-47622" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36479" id="CVE-2024-36479" title="CVE-2024-36479" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40976" id="CVE-2024-40976" title="CVE-2024-40976" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42105" id="CVE-2024-42105" title="CVE-2024-42105" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42148" id="CVE-2024-42148" title="CVE-2024-42148" type="cve"/>
		</references>
		<description>CVE-2023-52742:In the Linux kernel, the following vulnerability has been resolved:
net: USB: Fix wrong-direction WARNING in plusb.c
The syzbot fuzzer detected a bug in the plusb network driver: A
zero-length control-OUT transfer was treated as a read instead of a
write.  In modern kernels this error provokes a WARNING:
usb 1-1: BOGUS control dir, pipe 80000280 doesn't match bRequestType c0
WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411
usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
Modules linked in:
CPU: 1 PID: 4645 Comm: dhcpcd Not tainted
6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google
01/12/2023
RIP: 0010:usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411
...
Call Trace:
 &lt;TASK&gt;
 usb_start_wait_urb+0x101/0x4b0 drivers/usb/core/message.c:58
 usb_internal_control_msg drivers/usb/core/message.c:102 [inline]
 usb_control_msg+0x320/0x4a0 drivers/usb/core/message.c:153
 __usbnet_read_cmd+0xb9/0x390 drivers/net/usb/usbnet.c:2010
 usbnet_read_cmd+0x96/0xf0 drivers/net/usb/usbnet.c:2068
 pl_vendor_req drivers/net/usb/plusb.c:60 [inline]
 pl_set_QuickLink_features drivers/net/usb/plusb.c:75 [inline]
 pl_reset+0x2f/0xf0 drivers/net/usb/plusb.c:85
 usbnet_open+0xcc/0x5d0 drivers/net/usb/usbnet.c:889
 __dev_open+0x297/0x4d0 net/core/dev.c:1417
 __dev_change_flags+0x587/0x750 net/core/dev.c:8530
 dev_change_flags+0x97/0x170 net/core/dev.c:8602
 devinet_ioctl+0x15a2/0x1d70 net/ipv4/devinet.c:1147
 inet_ioctl+0x33f/0x380 net/ipv4/af_inet.c:979
 sock_do_ioctl+0xcc/0x230 net/socket.c:1169
 sock_ioctl+0x1f8/0x680 net/socket.c:1286
 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+0x197/0x210 fs/ioctl.c:856
 do_syscall_x64 arch/x86/entry/common.c:50 [inline]
 do_syscall_64+0x39/0xb0 arch/x86/entry/common.c:80
 entry_SYSCALL_64_after_hwframe+0x63/0xcd
The fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() and
remove the USB_DIR_IN flag.
CVE-2024-38565:In the Linux kernel, the following vulnerability has been resolved:
wifi: ar5523: enable proper endpoint verification
Syzkaller reports [1] hitting a warning about an endpoint in use
not having an expected type to it.
Fix the issue by checking for the existence of all proper
endpoints with their according types intact.
Sadly, this patch has not been tested on real hardware.
[1] Syzkaller report:
------------[ cut here ]------------
usb 1-1: BOGUS urb xfer, pipe 3 != type 1
WARNING: CPU: 0 PID: 3643 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504
...
Call Trace:
 &lt;TASK&gt;
 ar5523_cmd+0x41b/0x780 drivers/net/wireless/ath/ar5523/ar5523.c:275
 ar5523_cmd_read drivers/net/wireless/ath/ar5523/ar5523.c:302 [inline]
 ar5523_host_available drivers/net/wireless/ath/ar5523/ar5523.c:1376 [inline]
 ar5523_probe+0x14b0/0x1d10 drivers/net/wireless/ath/ar5523/ar5523.c:1655
 usb_probe_interface+0x30f/0x7f0 drivers/usb/core/driver.c:396
 call_driver_probe drivers/base/dd.c:560 [inline]
 really_probe+0x249/0xb90 drivers/base/dd.c:639
 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008
 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
 device_add+0xbd9/0x1e90 drivers/base/core.c:3517
 usb_set_configuration+0x101d/0x1900 drivers/usb/core/message.c:2170
 usb_generic_driver_probe+0xbe/0x100 drivers/usb/core/generic.c:238
 usb_probe_device+0xd8/0x2c0 drivers/usb/core/driver.c:293
 call_driver_probe drivers/base/dd.c:560 [inline]
 really_probe+0x249/0xb90 drivers/base/dd.c:639
 __driver_probe_device+0x1df/0x4d0 drivers/base/dd.c:778
 driver_probe_device+0x4c/0x1a0 drivers/base/dd.c:808
 __device_attach_driver+0x1d4/0x2e0 drivers/base/dd.c:936
 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:427
 __device_attach+0x1e4/0x530 drivers/base/dd.c:1008
 bus_probe_device+0x1e8/0x2a0 drivers/base/bus.c:487
 device_add+0xbd9/0x1e90 drivers/base/core.c:3517
 usb_new_device.cold+0x685/0x10ad drivers/usb/core/hub.c:2573
 hub_port_connect drivers/usb/core/hub.c:5353 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5497 [inline]
 port_event drivers/usb/core/hub.c:5653 [inline]
 hub_event+0x26cb/0x45d0 drivers/usb/core/hub.c:5735
 process_one_work+0x9bf/0x1710 kernel/workqueue.c:2289
 worker_thread+0x669/0x1090 kernel/workqueue.c:2436
 kthread+0x2e8/0x3a0 kernel/kthread.c:376
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:306
 &lt;/TASK&gt;
CVE-2024-39490:In the Linux kernel, the following vulnerability has been resolved:
ipv6: sr: fix missing sk_buff release in seg6_input_core
The seg6_input() function is responsible for adding the SRH into a
packet, delegating the operation to the seg6_input_core(). This function
uses the skb_cow_head() to ensure that there is sufficient headroom in
the sk_buff for accommodating the link-layer header.
In the event that the skb_cow_header() function fails, the
seg6_input_core() catches the error but it does not release the sk_buff,
which will result in a memory leak.
This issue was introduced in commit af3b5158b89d (&quot;ipv6: sr: fix BUG due
to headroom too small after SRH push&quot;) and persists even after commit
7a3f5b0de364 (&quot;netfilter: add netfilter hooks to SRv6 data plane&quot;),
where the entire seg6_input() code was refactored to deal with netfilter
hooks.
The proposed patch addresses the identified memory leak by requiring the
seg6_input_core() function to release the sk_buff in the event that
skb_cow_head() fails.
CVE-2024-41016:In the Linux kernel, the following vulnerability has been resolved:
ocfs2: strict bound check before memcmp in ocfs2_xattr_find_entry()
xattr in ocfs2 maybe 'non-indexed', which saved with additional space
requested.  It's better to check if the memory is out of bound before
memcmp, although this possibility mainly comes from crafted poisonous
images.
CVE-2024-42121:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check index msg_id before read or write
[WHAT]
msg_id is used as an array index and it cannot be a negative value, and
therefore cannot be equal to MOD_HDCP_MESSAGE_ID_INVALID (-1).
[HOW]
Check whether msg_id is valid before reading and setting.
This fixes 4 OVERRUN issues reported by Coverity.
CVE-2024-41098:In the Linux kernel, the following vulnerability has been resolved:
ata: libata-core: Fix null pointer dereference on error
If the ata_port_alloc() call in ata_host_alloc() fails,
ata_host_release() will get called.
However, the code in ata_host_release() tries to free ata_port struct
members unconditionally, which can lead to the following:
BUG: unable to handle page fault for address: 0000000000003990
PGD 0 P4D 0
Oops: Oops: 0000 [#1] PREEMPT SMP NOPTI
CPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014
RIP: 0010:ata_host_release.cold+0x2f/0x6e [libata]
Code: e4 4d 63 f4 44 89 e2 48 c7 c6 90 ad 32 c0 48 c7 c7 d0 70 33 c0 49 83 c6 0e 41
RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246
RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000
RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0
RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68
R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004
R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006
FS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0
PKRU: 55555554
Call Trace:
 &lt;TASK&gt;
 ? __die_body.cold+0x19/0x27
 ? page_fault_oops+0x15a/0x2f0
 ? exc_page_fault+0x7e/0x180
 ? asm_exc_page_fault+0x26/0x30
 ? ata_host_release.cold+0x2f/0x6e [libata]
 ? ata_host_release.cold+0x2f/0x6e [libata]
 release_nodes+0x35/0xb0
 devres_release_group+0x113/0x140
 ata_host_alloc+0xed/0x120 [libata]
 ata_host_alloc_pinfo+0x14/0xa0 [libata]
 ahci_init_one+0x6c9/0xd20 [ahci]
Do not access ata_port struct members unconditionally.
CVE-2023-52748:In the Linux kernel, the following vulnerability has been resolved:
f2fs: avoid format-overflow warning
With gcc and W=1 option, there's a warning like this:
fs/f2fs/compress.c: In function ‘f2fs_init_page_array_cache’:
fs/f2fs/compress.c:1984:47: error: ‘%u’ directive writing between
1 and 7 bytes into a region of size between 5 and 8
[-Werror=format-overflow=]
 1984 |  sprintf(slab_name, &quot;f2fs_page_array_entry-%u:%u&quot;, MAJOR(dev),
		MINOR(dev));
      |                                               ^~
String &quot;f2fs_page_array_entry-%u:%u&quot; can up to 35. The first &quot;%u&quot; can up
to 4 and the second &quot;%u&quot; can up to 7, so total size is &quot;24 + 4 + 7 = 35&quot;.
slab_name's size should be 35 rather than 32.
CVE-2024-42309:In the Linux kernel, the following vulnerability has been resolved:
drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modes
In psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() is
assigned to mode, which will lead to a possible NULL pointer dereference
on failure of drm_mode_duplicate(). Add a check to avoid npd.
CVE-2024-43828:In the Linux kernel, the following vulnerability has been resolved:
ext4: fix infinite loop when replaying fast_commit
When doing fast_commit replay an infinite loop may occur due to an
uninitialized extent_status struct.  ext4_ext_determine_insert_hole() does
not detect the replay and calls ext4_es_find_extent_range(), which will
return immediately without initializing the 'es' variable.
Because 'es' contains garbage, an integer overflow may happen causing an
infinite loop in this function, easily reproducible using fstest generic/039.
This commit fixes this issue by unconditionally initializing the structure
in function ext4_es_find_extent_range().
Thanks to Zhang Yi, for figuring out the real problem!
CVE-2024-41068:In the Linux kernel, the following vulnerability has been resolved:
s390/sclp: Fix sclp_init() cleanup on failure
If sclp_init() fails it only partially cleans up: if there are multiple
failing calls to sclp_init() sclp_state_change_event will be added several
times to sclp_reg_list, which results in the following warning:
------------[ cut here ]------------
list_add double add: new=000003ffe1598c10, prev=000003ffe1598bf0, next=000003ffe1598c10.
WARNING: CPU: 0 PID: 1 at lib/list_debug.c:35 __list_add_valid_or_report+0xde/0xf8
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3
Krnl PSW : 0404c00180000000 000003ffe0d6076a (__list_add_valid_or_report+0xe2/0xf8)
           R:0 T:1 IO:0 EX:0 Key:0 M:1 W:0 P:0 AS:3 CC:0 PM:0 RI:0 EA:3
...
Call Trace:
 [&lt;000003ffe0d6076a&gt;] __list_add_valid_or_report+0xe2/0xf8
([&lt;000003ffe0d60766&gt;] __list_add_valid_or_report+0xde/0xf8)
 [&lt;000003ffe0a8d37e&gt;] sclp_init+0x40e/0x450
 [&lt;000003ffe00009f2&gt;] do_one_initcall+0x42/0x1e0
 [&lt;000003ffe15b77a6&gt;] do_initcalls+0x126/0x150
 [&lt;000003ffe15b7a0a&gt;] kernel_init_freeable+0x1ba/0x1f8
 [&lt;000003ffe0d6650e&gt;] kernel_init+0x2e/0x180
 [&lt;000003ffe000301c&gt;] __ret_from_fork+0x3c/0x60
 [&lt;000003ffe0d759ca&gt;] ret_from_fork+0xa/0x30
Fix this by removing sclp_state_change_event from sclp_reg_list when
sclp_init() fails.
CVE-2024-42122:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add NULL pointer check for kzalloc
[Why &amp; How]
Check return pointer of kzalloc before using it.
CVE-2024-42322:In the Linux kernel, the following vulnerability has been resolved:
ipvs: properly dereference pe in ip_vs_add_service
Use pe directly to resolve sparse warning:
  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression
CVE-2024-42290:In the Linux kernel, the following vulnerability has been resolved:
irqchip/imx-irqsteer: Handle runtime power management correctly
The power domain is automatically activated from clk_prepare(). However, on
certain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokes
sleeping functions, which triggers the 'scheduling while atomic' bug in the
context switch path during device probing:
 BUG: scheduling while atomic: kworker/u13:1/48/0x00000002
 Call trace:
  __schedule_bug+0x54/0x6c
  __schedule+0x7f0/0xa94
  schedule+0x5c/0xc4
  schedule_preempt_disabled+0x24/0x40
  __mutex_lock.constprop.0+0x2c0/0x540
  __mutex_lock_slowpath+0x14/0x20
  mutex_lock+0x48/0x54
  clk_prepare_lock+0x44/0xa0
  clk_prepare+0x20/0x44
  imx_irqsteer_resume+0x28/0xe0
  pm_generic_runtime_resume+0x2c/0x44
  __genpd_runtime_resume+0x30/0x80
  genpd_runtime_resume+0xc8/0x2c0
  __rpm_callback+0x48/0x1d8
  rpm_callback+0x6c/0x78
  rpm_resume+0x490/0x6b4
  __pm_runtime_resume+0x50/0x94
  irq_chip_pm_get+0x2c/0xa0
  __irq_do_set_handler+0x178/0x24c
  irq_set_chained_handler_and_data+0x60/0xa4
  mxc_gpio_probe+0x160/0x4b0
Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chip
callbacks and handle power management in them as they are invoked from
non-atomic context.
[ tglx: Rewrote change log, added Fixes tag ]
CVE-2024-43824:In the Linux kernel, the following vulnerability has been resolved:
PCI: endpoint: pci-epf-test: Make use of cached 'epc_features' in pci_epf_test_core_init()
Instead of getting the epc_features from pci_epc_get_features() API, use
the cached pci_epf_test::epc_features value to avoid the NULL check. Since
the NULL check is already performed in pci_epf_test_bind(), having one more
check in pci_epf_test_core_init() is redundant and it is not possible to
hit the NULL pointer dereference.
Also with commit a01e7214bef9 (&quot;PCI: endpoint: Remove &quot;core_init_notifier&quot;
flag&quot;), 'epc_features' got dereferenced without the NULL check, leading to
the following false positive Smatch warning:
  drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed 'epc_features' could be null (see line 747)
Thus, remove the redundant NULL check and also use the epc_features::
{msix_capable/msi_capable} flags directly to avoid local variables.
[kwilczynski: commit log]
CVE-2024-42313:In the Linux kernel, the following vulnerability has been resolved:
media: venus: fix use after free in vdec_close
There appears to be a possible use after free with vdec_close().
The firmware will add buffer release work to the work queue through
HFI callbacks as a normal part of decoding. Randomly closing the
decoder device from userspace during normal decoding can incur
a read after free for inst.
Fix it by cancelling the work in vdec_close.
CVE-2024-43831:In the Linux kernel, the following vulnerability has been resolved:
media: mediatek: vcodec: Handle invalid decoder vsi
Handle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsi
is valid for future use.
CVE-2024-43860:In the Linux kernel, the following vulnerability has been resolved:
remoteproc: imx_rproc: Skip over memory region when node value is NULL
In imx_rproc_addr_init() &quot;nph = of_count_phandle_with_args()&quot; just counts
number of phandles. But phandles may be empty. So of_parse_phandle() in
the parsing loop (0 &lt; a &lt; nph) may return NULL which is later dereferenced.
Adjust this issue by adding NULL-return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
[Fixed title to fit within the prescribed 70-75 charcters]
CVE-2024-43819:In the Linux kernel, the following vulnerability has been resolved:
kvm: s390: Reject memory region operations for ucontrol VMs
This change rejects the KVM_SET_USER_MEMORY_REGION and
KVM_SET_USER_MEMORY_REGION2 ioctls when called on a ucontrol VM.
This is necessary since ucontrol VMs have kvm-&gt;arch.gmap set to 0 and
would thus result in a null pointer dereference further in.
Memory management needs to be performed in userspace and using the
ioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.
Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGION
and KVM_SET_USER_MEMORY_REGION2.
[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix]
CVE-2024-42126:In the Linux kernel, the following vulnerability has been resolved:
powerpc: Avoid nmi_enter/nmi_exit in real mode interrupt.
nmi_enter()/nmi_exit() touches per cpu variables which can lead to kernel
crash when invoked during real mode interrupt handling (e.g. early HMI/MCE
interrupt handler) if percpu allocation comes from vmalloc area.
Early HMI/MCE handlers are called through DEFINE_INTERRUPT_HANDLER_NMI()
wrapper which invokes nmi_enter/nmi_exit calls. We don't see any issue when
percpu allocation is from the embedded first chunk. However with
CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpu
allocation can come from the vmalloc area.
With kernel command line &quot;percpu_alloc=page&quot; we can force percpu allocation
to come from vmalloc area and can see kernel crash in machine_check_early:
[    1.215714] NIP [c000000000e49eb4] rcu_nmi_enter+0x24/0x110
[    1.215717] LR [c0000000000461a0] machine_check_early+0xf0/0x2c0
[    1.215719] --- interrupt: 200
[    1.215720] [c000000fffd73180] [0000000000000000] 0x0 (unreliable)
[    1.215722] [c000000fffd731b0] [0000000000000000] 0x0
[    1.215724] [c000000fffd73210] [c000000000008364] machine_check_early_common+0x134/0x1f8
Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpu
first chunk is not embedded.
CVE-2024-43823:In the Linux kernel, the following vulnerability has been resolved:
PCI: keystone: Fix NULL pointer dereference in case of DT error in ks_pcie_setup_rc_app_regs()
If IORESOURCE_MEM is not provided in Device Tree due to
any error, resource_list_first_type() will return NULL and
pci_parse_request_of_pci_ranges() will just emit a warning.
This will cause a NULL pointer dereference. Fix this bug by adding NULL
return check.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
CVE-2024-42281:In the Linux kernel, the following vulnerability has been resolved:
bpf: Fix a segment issue when downgrading gso_size
Linearize the skb when downgrading gso_size because it may trigger a
BUG_ON() later when the skb is segmented as described in [1,2].
CVE-2024-36946:In the Linux kernel, the following vulnerability has been resolved:
phonet: fix rtm_phonet_notify() skb allocation
fill_route() stores three components in the skb:
- struct rtmsg
- RTA_DST (u8)
- RTA_OIF (u32)
Therefore, rtm_phonet_notify() should use
NLMSG_ALIGN(sizeof(struct rtmsg)) +
nla_total_size(1) +
nla_total_size(4)
CVE-2024-38613:In the Linux kernel, the following vulnerability has been resolved:
m68k: Fix spinlock race in kernel thread creation
Context switching does take care to retain the correct lock owner across
the switch from 'prev' to 'next' tasks.  This does rely on interrupts
remaining disabled for the entire duration of the switch.
This condition is guaranteed for normal process creation and context
switching between already running processes, because both 'prev' and
'next' already have interrupts disabled in their saved copies of the
status register.
The situation is different for newly created kernel threads.  The status
register is set to PS_S in copy_thread(), which does leave the IPL at 0.
Upon restoring the 'next' thread's status register in switch_to() aka
resume(), interrupts then become enabled prematurely.  resume() then
returns via ret_from_kernel_thread() and schedule_tail() where run queue
lock is released (see finish_task_switch() and finish_lock_switch()).
A timer interrupt calling scheduler_tick() before the lock is released
in finish_task_switch() will find the lock already taken, with the
current task as lock owner.  This causes a spinlock recursion warning as
reported by Guenter Roeck.
As far as I can ascertain, this race has been opened in commit
533e6903bea0 (&quot;m68k: split ret_from_fork(), simplify kernel_thread()&quot;)
but I haven't done a detailed study of kernel history so it may well
predate that commit.
Interrupts cannot be disabled in the saved status register copy for
kernel threads (init will complain about interrupts disabled when
finally starting user space).  Disable interrupts temporarily when
switching the tasks' register sets in resume().
Note that a simple oriw 0x700,%sr after restoring sr is not enough here
- this leaves enough of a race for the 'spinlock recursion' warning to
still be observed.
Tested on ARAnyM and qemu (Quadra 800 emulation).
CVE-2024-40901:In the Linux kernel, the following vulnerability has been resolved:
scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memory
There is a potential out-of-bounds access when using test_bit() on a single
word. The test_bit() and set_bit() functions operate on long values, and
when testing or setting a single word, they can exceed the word
boundary. KASAN detects this issue and produces a dump:
	 BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas
	 Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965
For full log, please look at [1].
Make the allocation at least the size of sizeof(unsigned long) so that
set_bit() and test_bit() have sufficient room for read/write operations
without overwriting unallocated memory.
[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/
CVE-2024-41008:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: change vm-&gt;task_info handling
This patch changes the handling and lifecycle of vm-&gt;task_info object.
The major changes are:
- vm-&gt;task_info is a dynamically allocated ptr now, and its uasge is
  reference counted.
- introducing two new helper funcs for task_info lifecycle management
    - amdgpu_vm_get_task_info: reference counts up task_info before
      returning this info
    - amdgpu_vm_put_task_info: reference counts down task_info
- last put to task_info() frees task_info from the vm.
This patch also does logistical changes required for existing usage
of vm-&gt;task_info.
V2: Do not block all the prints when task_info not found (Felix)
V3: Fixed review comments from Felix
   - Fix wrong indentation
   - No debug message for -ENOMEM
   - Add NULL check for task_info
   - Do not duplicate the debug messages (ti vs no ti)
   - Get first reference of task_info in vm_init(), put last
     in vm_fini()
V4: Fixed review comments from Felix
   - fix double reference increment in create_task_info
   - change amdgpu_vm_get_task_info_pasid
   - additional changes in amdgpu_gem.c while porting
CVE-2023-52898:In the Linux kernel, the following vulnerability has been resolved:
xhci: Fix null pointer dereference when host dies
Make sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not race
and cause null pointer dereference when host suddenly dies.
Usb core may call xhci_free_dev() which frees the xhci-&gt;devs[slot_id]
virt device at the same time that xhci_kill_endpoint_urbs() tries to
loop through all the device's endpoints, checking if there are any
cancelled urbs left to give back.
hold the xhci spinlock while freeing the virt device
CVE-2022-48899:In the Linux kernel, the following vulnerability has been resolved:
drm/virtio: Fix GEM handle creation UAF
Userspace can guess the handle value and try to race GEM object creation
with handle close, resulting in a use-after-free if we dereference the
object after dropping the handle's reference.  For that reason, dropping
the handle's reference must be done *after* we are done dereferencing
the object.
CVE-2024-43879:In the Linux kernel, the following vulnerability has been resolved:
wifi: cfg80211: handle 2x996 RU allocation in cfg80211_calculate_bitrate_he()
Currently NL80211_RATE_INFO_HE_RU_ALLOC_2x996 is not handled in
cfg80211_calculate_bitrate_he(), leading to below warning:
kernel: invalid HE MCS: bw:6, ru:6
kernel: WARNING: CPU: 0 PID: 2312 at net/wireless/util.c:1501 cfg80211_calculate_bitrate_he+0x22b/0x270 [cfg80211]
Fix it by handling 2x996 RU allocation in the same way as 160 MHz bandwidth.
CVE-2022-48896:In the Linux kernel, the following vulnerability has been resolved:
ixgbe: fix pci device refcount leak
As the comment of pci_get_domain_bus_and_slot() says, it
returns a PCI device with refcount incremented, when finish
using it, the caller must decrement the reference count by
calling pci_dev_put().
In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),
pci_dev_put() is called to avoid leak.
CVE-2024-42297:In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to don't dirty inode for readonly filesystem
syzbot reports f2fs bug as below:
kernel BUG at fs/f2fs/inode.c:933!
RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933
Call Trace:
 evict+0x2a4/0x620 fs/inode.c:664
 dispose_list fs/inode.c:697 [inline]
 evict_inodes+0x5f8/0x690 fs/inode.c:747
 generic_shutdown_super+0x9d/0x2c0 fs/super.c:675
 kill_block_super+0x44/0x90 fs/super.c:1667
 kill_f2fs_super+0x303/0x3b0 fs/f2fs/super.c:4894
 deactivate_locked_super+0xc1/0x130 fs/super.c:484
 cleanup_mnt+0x426/0x4c0 fs/namespace.c:1256
 task_work_run+0x24a/0x300 kernel/task_work.c:180
 ptrace_notify+0x2cd/0x380 kernel/signal.c:2399
 ptrace_report_syscall include/linux/ptrace.h:411 [inline]
 ptrace_report_syscall_exit include/linux/ptrace.h:473 [inline]
 syscall_exit_work kernel/entry/common.c:251 [inline]
 syscall_exit_to_user_mode_prepare kernel/entry/common.c:278 [inline]
 __syscall_exit_to_user_mode_work kernel/entry/common.c:283 [inline]
 syscall_exit_to_user_mode+0x15c/0x280 kernel/entry/common.c:296
 do_syscall_64+0x50/0x110 arch/x86/entry/common.c:88
 entry_SYSCALL_64_after_hwframe+0x63/0x6b
The root cause is:
- do_sys_open
 - f2fs_lookup
  - __f2fs_find_entry
   - f2fs_i_depth_write
    - f2fs_mark_inode_dirty_sync
     - f2fs_dirty_inode
      - set_inode_flag(inode, FI_DIRTY_INODE)
- umount
 - kill_f2fs_super
  - kill_block_super
   - generic_shutdown_super
    - sync_filesystem
    : sb is readonly, skip sync_filesystem()
    - evict_inodes
     - iput
      - f2fs_evict_inode
       - f2fs_bug_on(sbi, is_inode_flag_set(inode, FI_DIRTY_INODE))
       : trigger kernel panic
When we try to repair i_current_depth in readonly filesystem, let's
skip dirty inode to avoid panic in later f2fs_evict_inode().
CVE-2024-43866:In the Linux kernel, the following vulnerability has been resolved:
net/mlx5: Always drain health in shutdown callback
There is no point in recovery during device shutdown. if health
work started need to wait for it to avoid races and NULL pointer
access.
Hence, drain health WQ on shutdown callback.
CVE-2024-42280:In the Linux kernel, the following vulnerability has been resolved:
mISDN: Fix a use after free in hfcmulti_tx()
Don't dereference *sp after calling dev_kfree_skb(*sp).
CVE-2023-52901:In the Linux kernel, the following vulnerability has been resolved:
usb: xhci: Check endpoint is valid before dereferencing it
When the host controller is not responding, all URBs queued to all
endpoints need to be killed. This can cause a kernel panic if we
dereference an invalid endpoint.
Fix this by using xhci_get_virt_ep() helper to find the endpoint and
checking if the endpoint is valid before dereferencing it.
[233311.853271] xhci-hcd xhci-hcd.1.auto: xHCI host controller not responding, assume dead
[233311.853393] Unable to handle kernel NULL pointer dereference at virtual address 00000000000000e8
[233311.853964] pc : xhci_hc_died+0x10c/0x270
[233311.853971] lr : xhci_hc_died+0x1ac/0x270
[233311.854077] Call trace:
[233311.854085]  xhci_hc_died+0x10c/0x270
[233311.854093]  xhci_stop_endpoint_command_watchdog+0x100/0x1a4
[233311.854105]  call_timer_fn+0x50/0x2d4
[233311.854112]  expire_timers+0xac/0x2e4
[233311.854118]  run_timer_softirq+0x300/0xabc
[233311.854127]  __do_softirq+0x148/0x528
[233311.854135]  irq_exit+0x194/0x1a8
[233311.854143]  __handle_domain_irq+0x164/0x1d0
[233311.854149]  gic_handle_irq.22273+0x10c/0x188
[233311.854156]  el1_irq+0xfc/0x1a8
[233311.854175]  lpm_cpuidle_enter+0x25c/0x418 [msm_pm]
[233311.854185]  cpuidle_enter_state+0x1f0/0x764
[233311.854194]  do_idle+0x594/0x6ac
[233311.854201]  cpu_startup_entry+0x7c/0x80
[233311.854209]  secondary_start_kernel+0x170/0x198
CVE-2023-52903:In the Linux kernel, the following vulnerability has been resolved:
io_uring: lock overflowing for IOPOLL
syzbot reports an issue with overflow filling for IOPOLL:
WARNING: CPU: 0 PID: 28 at io_uring/io_uring.c:734 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734
CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0
Workqueue: events_unbound io_ring_exit_work
Call trace:
 io_cqring_event_overflow+0x1c0/0x230 io_uring/io_uring.c:734
 io_req_cqe_overflow+0x5c/0x70 io_uring/io_uring.c:773
 io_fill_cqe_req io_uring/io_uring.h:168 [inline]
 io_do_iopoll+0x474/0x62c io_uring/rw.c:1065
 io_iopoll_try_reap_events+0x6c/0x108 io_uring/io_uring.c:1513
 io_uring_try_cancel_requests+0x13c/0x258 io_uring/io_uring.c:3056
 io_ring_exit_work+0xec/0x390 io_uring/io_uring.c:2869
 process_one_work+0x2d8/0x504 kernel/workqueue.c:2289
 worker_thread+0x340/0x610 kernel/workqueue.c:2436
 kthread+0x12c/0x158 kernel/kthread.c:376
 ret_from_fork+0x10/0x20 arch/arm64/kernel/entry.S:863
There is no real problem for normal IOPOLL as flush is also called with
uring_lock taken, but it's getting more complicated for IOPOLL|SQPOLL,
for which __io_cqring_overflow_flush() happens from the CQ waiting path.
CVE-2024-43882:In the Linux kernel, the following vulnerability has been resolved:
exec: Fix ToCToU between perm check and set-uid/gid usage
When opening a file for exec via do_filp_open(), permission checking is
done against the file's metadata at that moment, and on success, a file
pointer is passed back. Much later in the execve() code path, the file
metadata (specifically mode, uid, and gid) is used to determine if/how
to set the uid and gid. However, those values may have changed since the
permissions check, meaning the execution may gain unintended privileges.
For example, if a file could change permissions from executable and not
set-id:
---------x 1 root root 16048 Aug  7 13:16 target
to set-id and non-executable:
---S------ 1 root root 16048 Aug  7 13:16 target
it is possible to gain root privileges when execution should have been
disallowed.
While this race condition is rare in real-world scenarios, it has been
observed (and proven exploitable) when package managers are updating
the setuid bits of installed programs. Such files start with being
world-executable but then are adjusted to be group-exec with a set-uid
bit. For example, &quot;chmod o-x,u+s target&quot; makes &quot;target&quot; executable only
by uid &quot;root&quot; and gid &quot;cdrom&quot;, while also becoming setuid-root:
-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 target
becomes:
-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 target
But racing the chmod means users without group &quot;cdrom&quot; membership can
get the permission to execute &quot;target&quot; just before the chmod, and when
the chmod finishes, the exec reaches brpm_fill_uid(), and performs the
setuid to root, violating the expressed authorization of &quot;only cdrom
group members can setuid to root&quot;.
Re-check that we still have execute permissions in case the metadata
has changed. It would be better to keep a copy from the perm-check time,
but until we can do that refactoring, the least-bad option is to do a
full inode_permission() call (under inode lock). It is understood that
this is safe against dead-locks, but hardly optimal.
CVE-2024-43849:In the Linux kernel, the following vulnerability has been resolved:
soc: qcom: pdr: protect locator_addr with the main mutex
If the service locator server is restarted fast enough, the PDR can
rewrite locator_addr fields concurrently. Protect them by placing
modification of those fields under the main pdr-&gt;lock.
CVE-2024-42312:In the Linux kernel, the following vulnerability has been resolved:
sysctl: always initialize i_uid/i_gid
Always initialize i_uid/i_gid inside the sysfs core so set_ownership()
can safely skip setting them.
Commit 5ec27ec735ba (&quot;fs/proc/proc_sysctl.c: fix the default values of
i_uid/i_gid on /proc/sys inodes.&quot;) added defaults for i_uid/i_gid when
set_ownership() was not implemented. It also missed adjusting
net_ctl_set_ownership() to use the same default values in case the
computation of a better value failed.
CVE-2022-48873:In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: Don't remove map on creater_process and device_release
Do not remove the map from the list on error path in
fastrpc_init_create_process, instead call fastrpc_map_put, to avoid
use-after-free. Do not remove it on fastrpc_device_release either,
call fastrpc_map_put instead.
The fastrpc_free_map is the only proper place to remove the map.
This is called only after the reference count is 0.
CVE-2023-52893:In the Linux kernel, the following vulnerability has been resolved:
gsmi: fix null-deref in gsmi_get_variable
We can get EFI variables without fetching the attribute, so we must
allow for that in gsmi.
commit 859748255b43 (&quot;efi: pstore: Omit efivars caching EFI varstore
access layer&quot;) added a new get_variable call with attr=NULL, which
triggers panic in gsmi.
CVE-2024-42120:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Check pipe offset before setting vblank
pipe_ctx has a size of MAX_PIPES so checking its index before accessing
the array.
This fixes an OVERRUN issue reported by Coverity.
CVE-2022-48935:In the Linux kernel, the following vulnerability has been resolved:
netfilter: nf_tables: unregister flowtable hooks on netns exit
Unregister flowtable hooks before they are releases via
nf_tables_flowtable_destroy() otherwise hook core reports UAF.
BUG: KASAN: use-after-free in nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142
Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666
CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Call Trace:
 &lt;TASK&gt;
 __dump_stack lib/dump_stack.c:88 [inline]
 __dump_stack lib/dump_stack.c:88 [inline] lib/dump_stack.c:106
 dump_stack_lvl+0x1dc/0x2d8 lib/dump_stack.c:106 lib/dump_stack.c:106
 print_address_description+0x65/0x380 mm/kasan/report.c:247 mm/kasan/report.c:247
 __kasan_report mm/kasan/report.c:433 [inline]
 __kasan_report mm/kasan/report.c:433 [inline] mm/kasan/report.c:450
 kasan_report+0x19a/0x1f0 mm/kasan/report.c:450 mm/kasan/report.c:450
 nf_hook_entries_grow+0x5a7/0x700 net/netfilter/core.c:142 net/netfilter/core.c:142
 __nf_register_net_hook+0x27e/0x8d0 net/netfilter/core.c:429 net/netfilter/core.c:429
 nf_register_net_hook+0xaa/0x180 net/netfilter/core.c:571 net/netfilter/core.c:571
 nft_register_flowtable_net_hooks+0x3c5/0x730 net/netfilter/nf_tables_api.c:7232 net/netfilter/nf_tables_api.c:7232
 nf_tables_newflowtable+0x2022/0x2cf0 net/netfilter/nf_tables_api.c:7430 net/netfilter/nf_tables_api.c:7430
 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline]
 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline]
 nfnetlink_rcv_batch net/netfilter/nfnetlink.c:513 [inline] net/netfilter/nfnetlink.c:652
 nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:634 [inline] net/netfilter/nfnetlink.c:652
 nfnetlink_rcv+0x10e6/0x2550 net/netfilter/nfnetlink.c:652 net/netfilter/nfnetlink.c:652
__nft_release_hook() calls nft_unregister_flowtable_net_hooks() which
only unregisters the hooks, then after RCU grace period, it is
guaranteed that no packets add new entries to the flowtable (no flow
offload rules and flowtable hooks are reachable from packet path), so it
is safe to call nf_flow_table_free() which cleans up the remaining
entries from the flowtable (both software and hardware) and it unbinds
the flow_block.
CVE-2024-42308:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2024-42153:In the Linux kernel, the following vulnerability has been resolved:
i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isr
When del_timer_sync() is called in an interrupt context it throws a warning
because of potential deadlock. The timer is used only to exit from
wait_for_completion() after a timeout so replacing the call with
wait_for_completion_timeout() allows to remove the problematic timer and
its related functions altogether.
CVE-2022-48898:In the Linux kernel, the following vulnerability has been resolved:
drm/msm/dp: do not complete dp_aux_cmd_fifo_tx() if irq is not for aux transfer
There are 3 possible interrupt sources are handled by DP controller,
HPDstatus, Controller state changes and Aux read/write transaction.
At every irq, DP controller have to check isr status of every interrupt
sources and service the interrupt if its isr status bits shows interrupts
are pending. There is potential race condition may happen at current aux
isr handler implementation since it is always complete dp_aux_cmd_fifo_tx()
even irq is not for aux read or write transaction. This may cause aux read
transaction return premature if host aux data read is in the middle of
waiting for sink to complete transferring data to host while irq happen.
This will cause host's receiving buffer contains unexpected data. This
patch fixes this problem by checking aux isr and return immediately at
aux isr handler if there are no any isr status bits set.
Current there is a bug report regrading eDP edid corruption happen during
system booting up. After lengthy debugging to found that VIDEO_READY
interrupt was continuously firing during system booting up which cause
dp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve data
from aux hardware buffer which is not yet contains complete data transfer
from sink. This cause edid corruption.
Follows are the signature at kernel logs when problem happen,
EDID has corrupt header
panel-simple-dp-aux aux-aea0000.edp: Couldn't identify panel via EDID
Changes in v2:
-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()
-- add more commit text
Changes in v3:
-- add Stephen suggested
-- dp_aux_isr() return IRQ_XXX back to caller
-- dp_ctrl_isr() return IRQ_XXX back to caller
Changes in v4:
-- split into two patches
Changes in v5:
-- delete empty line between tags
Changes in v6:
-- remove extra &quot;that&quot; and fixed line more than 75 char at commit text
Patchwork: https://patchwork.freedesktop.org/patch/516121/
CVE-2024-42230:In the Linux kernel, the following vulnerability has been resolved:
powerpc/pseries: Fix scv instruction crash with kexec
kexec on pseries disables AIL (reloc_on_exc), required for scv
instruction support, before other CPUs have been shut down. This means
they can execute scv instructions after AIL is disabled, which causes an
interrupt at an unexpected entry location that crashes the kernel.
Change the kexec sequence to disable AIL after other CPUs have been
brought down.
As a refresher, the real-mode scv interrupt vector is 0x17000, and the
fixed-location head code probably couldn't easily deal with implementing
such high addresses so it was just decided not to support that interrupt
at all.
CVE-2024-42265:In the Linux kernel, the following vulnerability has been resolved:
protect the fetch of -&gt;fd[fd] in do_dup2() from mispredictions
both callers have verified that fd is not greater than -&gt;max_fds;
however, misprediction might end up with
        tofree = fdt-&gt;fd[fd];
being speculatively executed.  That's wrong for the same reasons
why it's wrong in close_fd()/file_close_fd_locked(); the same
solution applies - array_index_nospec(fd, fdt-&gt;max_fds) could differ
from fd only in case of speculative execution on mispredicted path.
CVE-2023-52896:In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix race between quota rescan and disable leading to NULL pointer deref
If we have one task trying to start the quota rescan worker while another
one is trying to disable quotas, we can end up hitting a race that results
in the quota rescan worker doing a NULL pointer dereference. The steps for
this are the following:
1) Quotas are enabled;
2) Task A calls the quota rescan ioctl and enters btrfs_qgroup_rescan().
   It calls qgroup_rescan_init() which returns 0 (success) and then joins a
   transaction and commits it;
3) Task B calls the quota disable ioctl and enters btrfs_quota_disable().
   It clears the bit BTRFS_FS_QUOTA_ENABLED from fs_info-&gt;flags and calls
   btrfs_qgroup_wait_for_completion(), which returns immediately since the
   rescan worker is not yet running.
   Then it starts a transaction and locks fs_info-&gt;qgroup_ioctl_lock;
4) Task A queues the rescan worker, by calling btrfs_queue_work();
5) The rescan worker starts, and calls rescan_should_stop() at the start
   of its while loop, which results in 0 iterations of the loop, since
   the flag BTRFS_FS_QUOTA_ENABLED was cleared from fs_info-&gt;flags by
   task B at step 3);
6) Task B sets fs_info-&gt;quota_root to NULL;
7) The rescan worker tries to start a transaction and uses
   fs_info-&gt;quota_root as the root argument for btrfs_start_transaction().
   This results in a NULL pointer dereference down the call chain of
   btrfs_start_transaction(). The stack trace is something like the one
   reported in Link tag below:
   general protection fault, probably for non-canonical address 0xdffffc0000000041: 0000 [#1] PREEMPT SMP KASAN
   KASAN: null-ptr-deref in range [0x0000000000000208-0x000000000000020f]
   CPU: 1 PID: 34 Comm: kworker/u4:2 Not tainted 6.1.0-syzkaller-13872-gb6bb9676f216 #0
   Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022
   Workqueue: btrfs-qgroup-rescan btrfs_work_helper
   RIP: 0010:start_transaction+0x48/0x10f0 fs/btrfs/transaction.c:564
   Code: 48 89 fb 48 (...)
   RSP: 0018:ffffc90000ab7ab0 EFLAGS: 00010206
   RAX: 0000000000000041 RBX: 0000000000000208 RCX: ffff88801779ba80
   RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000000
   RBP: dffffc0000000000 R08: 0000000000000001 R09: fffff52000156f5d
   R10: fffff52000156f5d R11: 1ffff92000156f5c R12: 0000000000000000
   R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000003
   FS:  0000000000000000(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000
   CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
   CR2: 00007f2bea75b718 CR3: 000000001d0cc000 CR4: 00000000003506e0
   DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
   DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
   Call Trace:
    &lt;TASK&gt;
    btrfs_qgroup_rescan_worker+0x3bb/0x6a0 fs/btrfs/qgroup.c:3402
    btrfs_work_helper+0x312/0x850 fs/btrfs/async-thread.c:280
    process_one_work+0x877/0xdb0 kernel/workqueue.c:2289
    worker_thread+0xb14/0x1330 kernel/workqueue.c:2436
    kthread+0x266/0x300 kernel/kthread.c:376
    ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:308
    &lt;/TASK&gt;
   Modules linked in:
So fix this by having the rescan worker function not attempt to start a
transaction if it didn't do any rescan work.
CVE-2024-43883:In the Linux kernel, the following vulnerability has been resolved:
usb: vhci-hcd: Do not drop references before new references are gained
At a few places the driver carries stale pointers
to references that can still be used. Make sure that does not happen.
This strictly speaking closes ZDI-CAN-22273, though there may be
similar races in the driver.
CVE-2022-48920:In the Linux kernel, the following vulnerability has been resolved:
btrfs: get rid of warning on transaction commit when using flushoncommit
When using the flushoncommit mount option, during almost every transaction
commit we trigger a warning from __writeback_inodes_sb_nr():
  $ cat fs/fs-writeback.c:
  (...)
  static void __writeback_inodes_sb_nr(struct super_block *sb, ...
  {
        (...)
        WARN_ON(!rwsem_is_locked(&amp;sb-&gt;s_umount));
        (...)
  }
  (...)
The trace produced in dmesg looks like the following:
  [947.473890] WARNING: CPU: 5 PID: 930 at fs/fs-writeback.c:2610 __writeback_inodes_sb_nr+0x7e/0xb3
  [947.481623] Modules linked in: nfsd nls_cp437 cifs asn1_decoder cifs_arc4 fscache cifs_md4 ipmi_ssif
  [947.489571] CPU: 5 PID: 930 Comm: btrfs-transacti Not tainted 95.16.3-srb-asrock-00001-g36437ad63879 #186
  [947.497969] RIP: 0010:__writeback_inodes_sb_nr+0x7e/0xb3
  [947.502097] Code: 24 10 4c 89 44 24 18 c6 (...)
  [947.519760] RSP: 0018:ffffc90000777e10 EFLAGS: 00010246
  [947.523818] RAX: 0000000000000000 RBX: 0000000000963300 RCX: 0000000000000000
  [947.529765] RDX: 0000000000000000 RSI: 000000000000fa51 RDI: ffffc90000777e50
  [947.535740] RBP: ffff888101628a90 R08: ffff888100955800 R09: ffff888100956000
  [947.541701] R10: 0000000000000002 R11: 0000000000000001 R12: ffff888100963488
  [947.547645] R13: ffff888100963000 R14: ffff888112fb7200 R15: ffff888100963460
  [947.553621] FS:  0000000000000000(0000) GS:ffff88841fd40000(0000) knlGS:0000000000000000
  [947.560537] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  [947.565122] CR2: 0000000008be50c4 CR3: 000000000220c000 CR4: 00000000001006e0
  [947.571072] Call Trace:
  [947.572354]  &lt;TASK&gt;
  [947.573266]  btrfs_commit_transaction+0x1f1/0x998
  [947.576785]  ? start_transaction+0x3ab/0x44e
  [947.579867]  ? schedule_timeout+0x8a/0xdd
  [947.582716]  transaction_kthread+0xe9/0x156
  [947.585721]  ? btrfs_cleanup_transaction.isra.0+0x407/0x407
  [947.590104]  kthread+0x131/0x139
  [947.592168]  ? set_kthread_struct+0x32/0x32
  [947.595174]  ret_from_fork+0x22/0x30
  [947.597561]  &lt;/TASK&gt;
  [947.598553] ---[ end trace 644721052755541c ]---
This is because we started using writeback_inodes_sb() to flush delalloc
when committing a transaction (when using -o flushoncommit), in order to
avoid deadlocks with filesystem freeze operations. This change was made
by commit ce8ea7cc6eb313 (&quot;btrfs: don't call btrfs_start_delalloc_roots
in flushoncommit&quot;). After that change we started producing that warning,
and every now and then a user reports this since the warning happens too
often, it spams dmesg/syslog, and a user is unsure if this reflects any
problem that might compromise the filesystem's reliability.
We can not just lock the sb-&gt;s_umount semaphore before calling
writeback_inodes_sb(), because that would at least deadlock with
filesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()
is called while we are holding that semaphore in write mode, and that can
trigger a transaction commit, resulting in a deadlock. It would also
trigger the same type of deadlock in the unmount path. Possibly, it could
also introduce some other locking dependencies that lockdep would report.
To fix this call try_to_writeback_inodes_sb() instead of
writeback_inodes_sb(), because that will try to read lock sb-&gt;s_umount
and then will only call writeback_inodes_sb() if it was able to lock it.
This is fine because the cases where it can't read lock sb-&gt;s_umount
are during a filesystem unmount or during a filesystem freeze - in those
cases sb-&gt;s_umount is write locked and sync_filesystem() is called, which
calls writeback_inodes_sb(). In other words, in all cases where we can't
take a read lock on sb-&gt;s_umount, writeback is already being triggered
elsewhere.
An alternative would be to call btrfs_start_delalloc_roots() with a
number of pages different from LONG_MAX, for example matching the number
of delalloc bytes we currently have, in 
---truncated---
CVE-2022-48871:In the Linux kernel, the following vulnerability has been resolved:
tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO buffer
Driver's probe allocates memory for RX FIFO (port-&gt;rx_fifo) based on
default RX FIFO depth, e.g. 16.  Later during serial startup the
qcom_geni_serial_port_setup() updates the RX FIFO depth
(port-&gt;rx_fifo_depth) to match real device capabilities, e.g. to 32.
The RX UART handle code will read &quot;port-&gt;rx_fifo_depth&quot; number of words
into &quot;port-&gt;rx_fifo&quot; buffer, thus exceeding the bounds.  This can be
observed in certain configurations with Qualcomm Bluetooth HCI UART
device and KASAN:
  Bluetooth: hci0: QCA Product ID   :0x00000010
  Bluetooth: hci0: QCA SOC Version  :0x400a0200
  Bluetooth: hci0: QCA ROM Version  :0x00000200
  Bluetooth: hci0: QCA Patch Version:0x00000d2b
  Bluetooth: hci0: QCA controller version 0x02000200
  Bluetooth: hci0: QCA Downloading qca/htbtfw20.tlv
  bluetooth hci0: Direct firmware load for qca/htbtfw20.tlv failed with error -2
  Bluetooth: hci0: QCA Failed to request file: qca/htbtfw20.tlv (-2)
  Bluetooth: hci0: QCA Failed to download patch (-2)
  ==================================================================
  BUG: KASAN: slab-out-of-bounds in handle_rx_uart+0xa8/0x18c
  Write of size 4 at addr ffff279347d578c0 by task swapper/0/0
  CPU: 0 PID: 0 Comm: swapper/0 Not tainted 6.1.0-rt5-00350-gb2450b7e00be-dirty #26
  Hardware name: Qualcomm Technologies, Inc. Robotics RB5 (DT)
  Call trace:
   dump_backtrace.part.0+0xe0/0xf0
   show_stack+0x18/0x40
   dump_stack_lvl+0x8c/0xb8
   print_report+0x188/0x488
   kasan_report+0xb4/0x100
   __asan_store4+0x80/0xa4
   handle_rx_uart+0xa8/0x18c
   qcom_geni_serial_handle_rx+0x84/0x9c
   qcom_geni_serial_isr+0x24c/0x760
   __handle_irq_event_percpu+0x108/0x500
   handle_irq_event+0x6c/0x110
   handle_fasteoi_irq+0x138/0x2cc
   generic_handle_domain_irq+0x48/0x64
If the RX FIFO depth changes after probe, be sure to resize the buffer.
CVE-2022-48877:In the Linux kernel, the following vulnerability has been resolved:
f2fs: let's avoid panic if extent_tree is not created
This patch avoids the below panic.
pc : __lookup_extent_tree+0xd8/0x760
lr : f2fs_do_write_data_page+0x104/0x87c
sp : ffffffc010cbb3c0
x29: ffffffc010cbb3e0 x28: 0000000000000000
x27: ffffff8803e7f020 x26: ffffff8803e7ed40
x25: ffffff8803e7f020 x24: ffffffc010cbb460
x23: ffffffc010cbb480 x22: 0000000000000000
x21: 0000000000000000 x20: ffffffff22e90900
x19: 0000000000000000 x18: ffffffc010c5d080
x17: 0000000000000000 x16: 0000000000000020
x15: ffffffdb1acdbb88 x14: ffffff888759e2b0
x13: 0000000000000000 x12: ffffff802da49000
x11: 000000000a001200 x10: ffffff8803e7ed40
x9 : ffffff8023195800 x8 : ffffff802da49078
x7 : 0000000000000001 x6 : 0000000000000000
x5 : 0000000000000006 x4 : ffffffc010cbba28
x3 : 0000000000000000 x2 : ffffffc010cbb480
x1 : 0000000000000000 x0 : ffffff8803e7ed40
Call trace:
 __lookup_extent_tree+0xd8/0x760
 f2fs_do_write_data_page+0x104/0x87c
 f2fs_write_single_data_page+0x420/0xb60
 f2fs_write_cache_pages+0x418/0xb1c
 __f2fs_write_data_pages+0x428/0x58c
 f2fs_write_data_pages+0x30/0x40
 do_writepages+0x88/0x190
 __writeback_single_inode+0x48/0x448
 writeback_sb_inodes+0x468/0x9e8
 __writeback_inodes_wb+0xb8/0x2a4
 wb_writeback+0x33c/0x740
 wb_do_writeback+0x2b4/0x400
 wb_workfn+0xe4/0x34c
 process_one_work+0x24c/0x5bc
 worker_thread+0x3e8/0xa50
 kthread+0x150/0x1b4
CVE-2024-42267:In the Linux kernel, the following vulnerability has been resolved:
riscv/mm: Add handling for VM_FAULT_SIGSEGV in mm_fault_error()
Handle VM_FAULT_SIGSEGV in the page fault path so that we correctly
kill the process and we don't BUG() the kernel.
CVE-2024-43890:In the Linux kernel, the following vulnerability has been resolved:
tracing: Fix overflow in get_free_elt()
&quot;tracing_map-&gt;next_elt&quot; in get_free_elt() is at risk of overflowing.
Once it overflows, new elements can still be inserted into the tracing_map
even though the maximum number of elements (`max_elts`) has been reached.
Continuing to insert elements after the overflow could result in the
tracing_map containing &quot;tracing_map-&gt;max_size&quot; elements, leaving no empty
entries.
If any attempt is made to insert an element into a full tracing_map using
`__tracing_map_insert()`, it will cause an infinite loop with preemption
disabled, leading to a CPU hang problem.
Fix this by preventing any further increments to &quot;tracing_map-&gt;next_elt&quot;
once it reaches &quot;tracing_map-&gt;max_elt&quot;.
CVE-2024-43854:In the Linux kernel, the following vulnerability has been resolved:
block: initialize integrity buffer to zero before writing it to media
Metadata added by bio_integrity_prep is using plain kmalloc, which leads
to random kernel memory being written media.  For PI metadata this is
limited to the app tag that isn't used by kernel generated metadata,
but for non-PI metadata the entire buffer leaks kernel memory.
Fix this by adding the __GFP_ZERO flag to allocations for writes.
CVE-2024-42299:In the Linux kernel, the following vulnerability has been resolved:
fs/ntfs3: Update log-&gt;page_{mask,bits} if log-&gt;page_size changed
If an NTFS file system is mounted to another system with different
PAGE_SIZE from the original system, log-&gt;page_size will change in
log_replay(), but log-&gt;page_{mask,bits} don't change correspondingly.
This will cause a panic because &quot;u32 bytes = log-&gt;page_size - page_off&quot;
will get a negative value in the later read_log_page().
CVE-2023-52880:In the Linux kernel, the following vulnerability has been resolved:
tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldisc
Any unprivileged user can attach N_GSM0710 ldisc, but it requires
CAP_NET_ADMIN to create a GSM network anyway.
Require initial namespace CAP_NET_ADMIN to do that.
CVE-2022-48811:In the Linux kernel, the following vulnerability has been resolved:
ibmvnic: don't release napi in __ibmvnic_open()
If __ibmvnic_open() encounters an error such as when setting link state,
it calls release_resources() which frees the napi structures needlessly.
Instead, have __ibmvnic_open() only clean up the work it did so far (i.e.
disable napi and irqs) and leave the rest to the callers.
If caller of __ibmvnic_open() is ibmvnic_open(), it should release the
resources immediately. If the caller is do_reset() or do_hard_reset(),
they will release the resources on the next reset.
This fixes following crash that occurred when running the drmgr command
several times to add/remove a vnic interface:
	[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq
	[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq
	[102056] ibmvnic 30000003 env3: Replenished 8 pools
	Kernel attempted to read user page (10) - exploit attempt? (uid: 0)
	BUG: Kernel NULL pointer dereference on read at 0x00000010
	Faulting instruction address: 0xc000000000a3c840
	Oops: Kernel access of bad area, sig: 11 [#1]
	LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries
	...
	CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1
	Workqueue: events_long __ibmvnic_reset [ibmvnic]
	NIP:  c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820
	REGS: c0000000548e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)
	MSR:  8000000000009033 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  CR: 28248484  XER: 00000004
	CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0
	GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000
	...
	NIP [c000000000a3c840] napi_enable+0x20/0xc0
	LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]
	Call Trace:
	[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)
	[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]
	[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]
	[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570
	[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660
	[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0
	[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64
	Instruction dump:
	7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010
	38a0fff6 e92d1100 f9210028 39200000 &lt;e9030010&gt; f9010020 60420000 e9210020
	---[ end trace 5f8033b08fd27706 ]---
CVE-2024-42288:In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: Fix for possible memory corruption
Init Control Block is dereferenced incorrectly.  Correctly dereference ICB
CVE-2024-43908:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: Fix the null pointer dereference to ras_manager
Check ras_manager before using it
CVE-2024-42286:In the Linux kernel, the following vulnerability has been resolved:
scsi: qla2xxx: validate nvme_local_port correctly
The driver load failed with error message,
qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffef
and with a kernel crash,
	BUG: unable to handle kernel NULL pointer dereference at 0000000000000070
	Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]
	RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]
	RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282
	RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000
	RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000
	RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030
	R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4
	R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8
	FS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000
	CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
	CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0
	Call Trace:
	qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]
	? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]
	qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]
	qla_register_fcport_fn+0x54/0xc0 [qla2xxx]
Exit the qla_nvme_register_remote() function when qla_nvme_register_hba()
fails and correctly validate nvme_local_port.
CVE-2023-52889:In the Linux kernel, the following vulnerability has been resolved:
apparmor: Fix null pointer deref when receiving skb during sock creation
The panic below is observed when receiving ICMP packets with secmark set
while an ICMP raw socket is being created. SK_CTX(sk)-&gt;label is updated
in apparmor_socket_post_create(), but the packet is delivered to the
socket before that, causing the null pointer dereference.
Drop the packet if label context is not set.
    BUG: kernel NULL pointer dereference, address: 000000000000004c
    #PF: supervisor read access in kernel mode
    #PF: error_code(0x0000) - not-present page
    PGD 0 P4D 0
    Oops: 0000 [#1] PREEMPT SMP NOPTI
    CPU: 0 PID: 407 Comm: a.out Not tainted 6.4.12-arch1-1 #1 3e6fa2753a2d75925c34ecb78e22e85a65d083df
    Hardware name: VMware, Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 05/28/2020
    RIP: 0010:aa_label_next_confined+0xb/0x40
    Code: 00 00 48 89 ef e8 d5 25 0c 00 e9 66 ff ff ff 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 0f 1f 00 0f 1f 44 00 00 89 f0 &lt;8b&gt; 77 4c 39 c6 7e 1f 48 63 d0 48 8d 14 d7 eb 0b 83 c0 01 48 83 c2
    RSP: 0018:ffffa92940003b08 EFLAGS: 00010246
    RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000e
    RDX: ffffa92940003be8 RSI: 0000000000000000 RDI: 0000000000000000
    RBP: ffff8b57471e7800 R08: ffff8b574c642400 R09: 0000000000000002
    R10: ffffffffbd820eeb R11: ffffffffbeb7ff00 R12: ffff8b574c642400
    R13: 0000000000000001 R14: 0000000000000001 R15: 0000000000000000
    FS:  00007fb092ea7640(0000) GS:ffff8b577bc00000(0000) knlGS:0000000000000000
    CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
    CR2: 000000000000004c CR3: 00000001020f2005 CR4: 00000000007706f0
    PKRU: 55555554
    Call Trace:
     &lt;IRQ&gt;
     ? __die+0x23/0x70
     ? page_fault_oops+0x171/0x4e0
     ? exc_page_fault+0x7f/0x180
     ? asm_exc_page_fault+0x26/0x30
     ? aa_label_next_confined+0xb/0x40
     apparmor_secmark_check+0xec/0x330
     security_sock_rcv_skb+0x35/0x50
     sk_filter_trim_cap+0x47/0x250
     sock_queue_rcv_skb_reason+0x20/0x60
     raw_rcv+0x13c/0x210
     raw_local_deliver+0x1f3/0x250
     ip_protocol_deliver_rcu+0x4f/0x2f0
     ip_local_deliver_finish+0x76/0xa0
     __netif_receive_skb_one_core+0x89/0xa0
     netif_receive_skb+0x119/0x170
     ? __netdev_alloc_skb+0x3d/0x140
     vmxnet3_rq_rx_complete+0xb23/0x1010 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
     vmxnet3_poll_rx_only+0x36/0xb0 [vmxnet3 56a84f9c97178c57a43a24ec073b45a9d6f01f3a]
     __napi_poll+0x28/0x1b0
     net_rx_action+0x2a4/0x380
     __do_softirq+0xd1/0x2c8
     __irq_exit_rcu+0xbb/0xf0
     common_interrupt+0x86/0xa0
     &lt;/IRQ&gt;
     &lt;TASK&gt;
     asm_common_interrupt+0x26/0x40
    RIP: 0010:apparmor_socket_post_create+0xb/0x200
    Code: 08 48 85 ff 75 a1 eb b1 0f 1f 80 00 00 00 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 f3 0f 1e fa 0f 1f 44 00 00 41 54 &lt;55&gt; 48 89 fd 53 45 85 c0 0f 84 b2 00 00 00 48 8b 1d 80 56 3f 02 48
    RSP: 0018:ffffa92940ce7e50 EFLAGS: 00000286
    RAX: ffffffffbc756440 RBX: 0000000000000000 RCX: 0000000000000001
    RDX: 0000000000000003 RSI: 0000000000000002 RDI: ffff8b574eaab740
    RBP: 0000000000000001 R08: 0000000000000000 R09: 0000000000000000
    R10: ffff8b57444cec70 R11: 0000000000000000 R12: 0000000000000003
    R13: 0000000000000002 R14: ffff8b574eaab740 R15: ffffffffbd8e4748
     ? __pfx_apparmor_socket_post_create+0x10/0x10
     security_socket_post_create+0x4b/0x80
     __sock_create+0x176/0x1f0
     __sys_socket+0x89/0x100
     __x64_sys_socket+0x17/0x20
     do_syscall_64+0x5d/0x90
     ? do_syscall_64+0x6c/0x90
     ? do_syscall_64+0x6c/0x90
     ? do_syscall_64+0x6c/0x90
     entry_SYSCALL_64_after_hwframe+0x72/0xdc
CVE-2024-43884:In the Linux kernel, the following vulnerability has been resolved:
Bluetooth: MGMT: Add error handling to pair_device()
hci_conn_params_add() never checks for a NULL value and could lead to a NULL
pointer dereference causing a crash.
Fixed by adding error handling in the function.
CVE-2024-43907:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rules
Check the pointer value to fix potential null pointer
dereference
CVE-2024-44938:In the Linux kernel, the following vulnerability has been resolved:
jfs: Fix shift-out-of-bounds in dbDiscardAG
When searching for the next smaller log2 block, BLKSTOL2() returned 0,
causing shift exponent -1 to be negative.
This patch fixes the issue by exiting the loop directly when negative
shift is found.
CVE-2024-43892:In the Linux kernel, the following vulnerability has been resolved:
memcg: protect concurrent access to mem_cgroup_idr
Commit 73f576c04b94 (&quot;mm: memcontrol: fix cgroup creation failure after
many small jobs&quot;) decoupled the memcg IDs from the CSS ID space to fix the
cgroup creation failures.  It introduced IDR to maintain the memcg ID
space.  The IDR depends on external synchronization mechanisms for
modifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()
happen within css callback and thus are protected through cgroup_mutex
from concurrent modifications.  However idr_remove() for mem_cgroup_idr
was not protected against concurrency and can be run concurrently for
different memcgs when they hit their refcnt to zero.  Fix that.
We have been seeing list_lru based kernel crashes at a low frequency in
our fleet for a long time.  These crashes were in different part of
list_lru code including list_lru_add(), list_lru_del() and reparenting
code.  Upon further inspection, it looked like for a given object (dentry
and inode), the super_block's list_lru didn't have list_lru_one for the
memcg of that object.  The initial suspicions were either the object is
not allocated through kmem_cache_alloc_lru() or somehow
memcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg but
returned success.  No evidence were found for these cases.
Looking more deeply, we started seeing situations where valid memcg's id
is not present in mem_cgroup_idr and in some cases multiple valid memcgs
have same id and mem_cgroup_idr is pointing to one of them.  So, the most
reasonable explanation is that these situations can happen due to race
between multiple idr_remove() calls or race between
idr_alloc()/idr_replace() and idr_remove().  These races are causing
multiple memcgs to acquire the same ID and then offlining of one of them
would cleanup list_lrus on the system for all of them.  Later access from
other memcgs to the list_lru cause crashes due to missing list_lru_one.
CVE-2024-44934:In the Linux kernel, the following vulnerability has been resolved:
net: bridge: mcast: wait for previous gc cycles when removing port
syzbot hit a use-after-free[1] which is caused because the bridge doesn't
make sure that all previous garbage has been collected when removing a
port. What happens is:
      CPU 1                   CPU 2
 start gc cycle           remove port
                         acquire gc lock first
 wait for lock
                         call br_multicasg_gc() directly
 acquire lock now but    free port
 the port can be freed
 while grp timers still
 running
Make sure all previous gc cycles have finished by using flush_work before
freeing the port.
[1]
  BUG: KASAN: slab-use-after-free in br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861
  Read of size 8 at addr ffff888071d6d000 by task syz.5.1232/9699
  CPU: 1 PID: 9699 Comm: syz.5.1232 Not tainted 6.10.0-rc5-syzkaller-00021-g24ca36a562d6 #0
  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
  Call Trace:
   &lt;IRQ&gt;
   __dump_stack lib/dump_stack.c:88 [inline]
   dump_stack_lvl+0x116/0x1f0 lib/dump_stack.c:114
   print_address_description mm/kasan/report.c:377 [inline]
   print_report+0xc3/0x620 mm/kasan/report.c:488
   kasan_report+0xd9/0x110 mm/kasan/report.c:601
   br_multicast_port_group_expired+0x4c0/0x550 net/bridge/br_multicast.c:861
   call_timer_fn+0x1a3/0x610 kernel/time/timer.c:1792
   expire_timers kernel/time/timer.c:1843 [inline]
   __run_timers+0x74b/0xaf0 kernel/time/timer.c:2417
   __run_timer_base kernel/time/timer.c:2428 [inline]
   __run_timer_base kernel/time/timer.c:2421 [inline]
   run_timer_base+0x111/0x190 kernel/time/timer.c:2437
CVE-2024-43893:In the Linux kernel, the following vulnerability has been resolved:
serial: core: check uartclk for zero to avoid divide by zero
Calling ioctl TIOCSSERIAL with an invalid baud_base can
result in uartclk being zero, which will result in a
divide by zero error in uart_get_divisor(). The check for
uartclk being zero in uart_set_info() needs to be done
before other settings are made as subsequent calls to
ioctl TIOCSSERIAL for the same port would be impacted if
the uartclk check was done where uartclk gets set.
Oops: divide error: 0000  PREEMPT SMP KASAN PTI
RIP: 0010:uart_get_divisor (drivers/tty/serial/serial_core.c:580)
Call Trace:
 &lt;TASK&gt;
serial8250_get_divisor (drivers/tty/serial/8250/8250_port.c:2576
    drivers/tty/serial/8250/8250_port.c:2589)
serial8250_do_set_termios (drivers/tty/serial/8250/8250_port.c:502
    drivers/tty/serial/8250/8250_port.c:2741)
serial8250_set_termios (drivers/tty/serial/8250/8250_port.c:2862)
uart_change_line_settings (./include/linux/spinlock.h:376
    ./include/linux/serial_core.h:608 drivers/tty/serial/serial_core.c:222)
uart_port_startup (drivers/tty/serial/serial_core.c:342)
uart_startup (drivers/tty/serial/serial_core.c:368)
uart_set_info (drivers/tty/serial/serial_core.c:1034)
uart_set_info_user (drivers/tty/serial/serial_core.c:1059)
tty_set_serial (drivers/tty/tty_io.c:2637)
tty_ioctl (drivers/tty/tty_io.c:2647 drivers/tty/tty_io.c:2791)
__x64_sys_ioctl (fs/ioctl.c:52 fs/ioctl.c:907
    fs/ioctl.c:893 fs/ioctl.c:893)
do_syscall_64 (arch/x86/entry/common.c:52
    (discriminator 1) arch/x86/entry/common.c:83 (discriminator 1))
entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)
Rule: add
CVE-2023-52906:In the Linux kernel, the following vulnerability has been resolved:
net/sched: act_mpls: Fix warning during failed attribute validation
The 'TCA_MPLS_LABEL' attribute is of 'NLA_U32' type, but has a
validation type of 'NLA_VALIDATE_FUNCTION'. This is an invalid
combination according to the comment above 'struct nla_policy':
&quot;
Meaning of `validate' field, use via NLA_POLICY_VALIDATE_FN:
   NLA_BINARY           Validation function called for the attribute.
   All other            Unused - but note that it's a union
&quot;
This can trigger the warning [1] in nla_get_range_unsigned() when
validation of the attribute fails. Despite being of 'NLA_U32' type, the
associated 'min'/'max' fields in the policy are negative as they are
aliased by the 'validate' field.
Fix by changing the attribute type to 'NLA_BINARY' which is consistent
with the above comment and all other users of NLA_POLICY_VALIDATE_FN().
As a result, move the length validation to the validation function.
No regressions in MPLS tests:
 # ./tdc.py -f tc-tests/actions/mpls.json
 [...]
 # echo $?
 0
[1]
WARNING: CPU: 0 PID: 17743 at lib/nlattr.c:118
nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
Modules linked in:
CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
rel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014
RIP: 0010:nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117
[...]
Call Trace:
 &lt;TASK&gt;
 __netlink_policy_dump_write_attr+0x23d/0x990 net/netlink/policy.c:310
 netlink_policy_dump_write_attr+0x22/0x30 net/netlink/policy.c:411
 netlink_ack_tlv_fill net/netlink/af_netlink.c:2454 [inline]
 netlink_ack+0x546/0x760 net/netlink/af_netlink.c:2506
 netlink_rcv_skb+0x1b7/0x240 net/netlink/af_netlink.c:2546
 rtnetlink_rcv+0x18/0x20 net/core/rtnetlink.c:6109
 netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
 netlink_unicast+0x5e9/0x6b0 net/netlink/af_netlink.c:1345
 netlink_sendmsg+0x739/0x860 net/netlink/af_netlink.c:1921
 sock_sendmsg_nosec net/socket.c:714 [inline]
 sock_sendmsg net/socket.c:734 [inline]
 ____sys_sendmsg+0x38f/0x500 net/socket.c:2482
 ___sys_sendmsg net/socket.c:2536 [inline]
 __sys_sendmsg+0x197/0x230 net/socket.c:2565
 __do_sys_sendmsg net/socket.c:2574 [inline]
 __se_sys_sendmsg net/socket.c:2572 [inline]
 __x64_sys_sendmsg+0x42/0x50 net/socket.c:2572
 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
CVE-2022-48872:In the Linux kernel, the following vulnerability has been resolved:
misc: fastrpc: Fix use-after-free race condition for maps
It is possible that in between calling fastrpc_map_get() until
map-&gt;fl-&gt;lock is taken in fastrpc_free_map(), another thread can call
fastrpc_map_lookup() and get a reference to a map that is about to be
deleted.
Rewrite fastrpc_map_get() to only increase the reference count of a map
if it's non-zero. Propagate this to callers so they can know if a map is
about to be deleted.
Fixes this warning:
refcount_t: addition on 0; use-after-free.
WARNING: CPU: 5 PID: 10100 at lib/refcount.c:25 refcount_warn_saturate
...
Call trace:
 refcount_warn_saturate
 [fastrpc_map_get inlined]
 [fastrpc_map_lookup inlined]
 fastrpc_map_create
 fastrpc_internal_invoke
 fastrpc_device_ioctl
 __arm64_sys_ioctl
 invoke_syscall
CVE-2024-43905:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: Fix the null pointer dereference for vega10_hwmgr
Check return value and conduct null pointer handling to avoid null pointer dereference.
CVE-2023-52899:In the Linux kernel, the following vulnerability has been resolved:
Add exception protection processing for vd in axi_chan_handle_err function
Since there is no protection for vd, a kernel panic will be
triggered here in exceptional cases.
You can refer to the processing of axi_chan_block_xfer_complete function
The triggered kernel panic is as follows:
[   67.848444] Unable to handle kernel NULL pointer dereference at virtual address 0000000000000060
[   67.848447] Mem abort info:
[   67.848449]   ESR = 0x96000004
[   67.848451]   EC = 0x25: DABT (current EL), IL = 32 bits
[   67.848454]   SET = 0, FnV = 0
[   67.848456]   EA = 0, S1PTW = 0
[   67.848458] Data abort info:
[   67.848460]   ISV = 0, ISS = 0x00000004
[   67.848462]   CM = 0, WnR = 0
[   67.848465] user pgtable: 4k pages, 48-bit VAs, pgdp=00000800c4c0b000
[   67.848468] [0000000000000060] pgd=0000000000000000, p4d=0000000000000000
[   67.848472] Internal error: Oops: 96000004 [#1] SMP
[   67.848475] Modules linked in: dmatest
[   67.848479] CPU: 0 PID: 0 Comm: swapper/0 Not tainted 5.10.100-emu_x2rc+ #11
[   67.848483] pstate: 62000085 (nZCv daIf -PAN -UAO +TCO BTYPE=--)
[   67.848487] pc : axi_chan_handle_err+0xc4/0x230
[   67.848491] lr : axi_chan_handle_err+0x30/0x230
[   67.848493] sp : ffff0803fe55ae50
[   67.848495] x29: ffff0803fe55ae50 x28: ffff800011212200
[   67.848500] x27: ffff0800c42c0080 x26: ffff0800c097c080
[   67.848504] x25: ffff800010d33880 x24: ffff80001139d850
[   67.848508] x23: ffff0800c097c168 x22: 0000000000000000
[   67.848512] x21: 0000000000000080 x20: 0000000000002000
[   67.848517] x19: ffff0800c097c080 x18: 0000000000000000
[   67.848521] x17: 0000000000000000 x16: 0000000000000000
[   67.848525] x15: 0000000000000000 x14: 0000000000000000
[   67.848529] x13: 0000000000000000 x12: 0000000000000040
[   67.848533] x11: ffff0800c0400248 x10: ffff0800c040024a
[   67.848538] x9 : ffff800010576cd4 x8 : ffff0800c0400270
[   67.848542] x7 : 0000000000000000 x6 : ffff0800c04003e0
[   67.848546] x5 : ffff0800c0400248 x4 : ffff0800c4294480
[   67.848550] x3 : dead000000000100 x2 : dead000000000122
[   67.848555] x1 : 0000000000000100 x0 : ffff0800c097c168
[   67.848559] Call trace:
[   67.848562]  axi_chan_handle_err+0xc4/0x230
[   67.848566]  dw_axi_dma_interrupt+0xf4/0x590
[   67.848569]  __handle_irq_event_percpu+0x60/0x220
[   67.848573]  handle_irq_event+0x64/0x120
[   67.848576]  handle_fasteoi_irq+0xc4/0x220
[   67.848580]  __handle_domain_irq+0x80/0xe0
[   67.848583]  gic_handle_irq+0xc0/0x138
[   67.848585]  el1_irq+0xc8/0x180
[   67.848588]  arch_cpu_idle+0x14/0x2c
[   67.848591]  default_idle_call+0x40/0x16c
[   67.848594]  do_idle+0x1f0/0x250
[   67.848597]  cpu_startup_entry+0x2c/0x60
[   67.848600]  rest_init+0xc0/0xcc
[   67.848603]  arch_call_rest_init+0x14/0x1c
[   67.848606]  start_kernel+0x4cc/0x500
[   67.848610] Code: eb0002ff 9a9f12d6 f2fbd5a2 f2fbd5a3 (a94602c1)
[   67.848613] ---[ end trace 585a97036f88203a ]---
CVE-2024-43889:In the Linux kernel, the following vulnerability has been resolved:
padata: Fix possible divide-by-0 panic in padata_mt_helper()
We are hit with a not easily reproducible divide-by-0 panic in padata.c at
bootup time.
  [   10.017908] Oops: divide error: 0000 1 PREEMPT SMP NOPTI
  [   10.017908] CPU: 26 PID: 2627 Comm: kworker/u1666:1 Not tainted 6.10.0-15.el10.x86_64 #1
  [   10.017908] Hardware name: Lenovo ThinkSystem SR950 [7X12CTO1WW]/[7X12CTO1WW], BIOS [PSE140J-2.30] 07/20/2021
  [   10.017908] Workqueue: events_unbound padata_mt_helper
  [   10.017908] RIP: 0010:padata_mt_helper+0x39/0xb0
    :
  [   10.017963] Call Trace:
  [   10.017968]  &lt;TASK&gt;
  [   10.018004]  ? padata_mt_helper+0x39/0xb0
  [   10.018084]  process_one_work+0x174/0x330
  [   10.018093]  worker_thread+0x266/0x3a0
  [   10.018111]  kthread+0xcf/0x100
  [   10.018124]  ret_from_fork+0x31/0x50
  [   10.018138]  ret_from_fork_asm+0x1a/0x30
  [   10.018147]  &lt;/TASK&gt;
Looking at the padata_mt_helper() function, the only way a divide-by-0
panic can happen is when ps-&gt;chunk_size is 0.  The way that chunk_size is
initialized in padata_do_multithreaded(), chunk_size can be 0 when the
min_chunk in the passed-in padata_mt_job structure is 0.
Fix this divide-by-0 panic by making sure that chunk_size will be at least
1 no matter what the input parameters are.
CVE-2024-41060:In the Linux kernel, the following vulnerability has been resolved:
drm/radeon: check bo_va-&gt;bo is non-NULL before using it
The call to radeon_vm_clear_freed might clear bo_va-&gt;bo, so
we have to check it before dereferencing it.
CVE-2024-41082:In the Linux kernel, the following vulnerability has been resolved:
nvme-fabrics: use reserved tag for reg read/write command
In some scenarios, if too many commands are issued by nvme command in
the same time by user tasks, this may exhaust all tags of admin_q. If
a reset (nvme reset or IO timeout) occurs before these commands finish,
reconnect routine may fail to update nvme regs due to insufficient tags,
which will cause kernel hang forever. In order to workaround this issue,
maybe we can let reg_read32()/reg_read64()/reg_write32() use reserved
tags. This maybe safe for nvmf:
1. For the disable ctrl path,  we will not issue connect command
2. For the enable ctrl / fw activate path, since connect and reg_xx()
   are called serially.
So the reserved tags may still be enough while reg_xx() use reserved tags.
CVE-2022-48879:In the Linux kernel, the following vulnerability has been resolved:
efi: fix NULL-deref in init error path
In cases where runtime services are not supported or have been disabled,
the runtime services workqueue will never have been allocated.
Do not try to destroy the workqueue unconditionally in the unlikely
event that EFI initialisation fails to avoid dereferencing a NULL
pointer.
CVE-2024-43856:In the Linux kernel, the following vulnerability has been resolved:
dma: fix call order in dmam_free_coherent
dmam_free_coherent() frees a DMA allocation, which makes the
freed vaddr available for reuse, then calls devres_destroy()
to remove and free the data structure used to track the DMA
allocation. Between the two calls, it is possible for a
concurrent task to make an allocation with the same vaddr
and add it to the devres list.
If this happens, there will be two entries in the devres list
with the same vaddr and devres_destroy() can free the wrong
entry, triggering the WARN_ON() in dmam_match.
Fix by destroying the devres entry before freeing the DMA
allocation.
  kokonut //net/encryption
    http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03
CVE-2024-44944:In the Linux kernel, the following vulnerability has been resolved:
netfilter: ctnetlink: use helper function to calculate expect ID
Delete expectation path is missing a call to the nf_expect_get_id()
helper function to calculate the expectation ID, otherwise LSB of the
expectation object address is leaked to userspace.
CVE-2024-43898:Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.
CVE-2022-48891:In the Linux kernel, the following vulnerability has been resolved:
regulator: da9211: Use irq handler when ready
If the system does not come from reset (like when it is kexec()), the
regulator might have an IRQ waiting for us.
If we enable the IRQ handler before its structures are ready, we crash.
This patch fixes:
[    1.141839] Unable to handle kernel read from unreadable memory at virtual address 0000000000000078
[    1.316096] Call trace:
[    1.316101]  blocking_notifier_call_chain+0x20/0xa8
[    1.322757] cpu cpu0: dummy supplies not allowed for exclusive requests
[    1.327823]  regulator_notifier_call_chain+0x1c/0x2c
[    1.327825]  da9211_irq_handler+0x68/0xf8
[    1.327829]  irq_thread+0x11c/0x234
[    1.327833]  kthread+0x13c/0x154
CVE-2024-44946:In the Linux kernel, the following vulnerability has been resolved:
kcm: Serialise kcm_sendmsg() for the same socket.
syzkaller reported UAF in kcm_release(). [0]
The scenario is
  1. Thread A builds a skb with MSG_MORE and sets kcm-&gt;seq_skb.
  2. Thread A resumes building skb from kcm-&gt;seq_skb but is blocked
     by sk_stream_wait_memory()
  3. Thread B calls sendmsg() concurrently, finishes building kcm-&gt;seq_skb
     and puts the skb to the write queue
  4. Thread A faces an error and finally frees skb that is already in the
     write queue
  5. kcm_release() does double-free the skb in the write queue
When a thread is building a MSG_MORE skb, another thread must not touch it.
Let's add a per-sk mutex and serialise kcm_sendmsg().
[0]:
BUG: KASAN: slab-use-after-free in __skb_unlink include/linux/skbuff.h:2366 [inline]
BUG: KASAN: slab-use-after-free in __skb_dequeue include/linux/skbuff.h:2385 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
BUG: KASAN: slab-use-after-free in __skb_queue_purge include/linux/skbuff.h:3181 [inline]
BUG: KASAN: slab-use-after-free in kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167
CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024
Call trace:
 dump_backtrace+0x1b8/0x1e4 arch/arm64/kernel/stacktrace.c:291
 show_stack+0x2c/0x3c arch/arm64/kernel/stacktrace.c:298
 __dump_stack lib/dump_stack.c:88 [inline]
 dump_stack_lvl+0xd0/0x124 lib/dump_stack.c:106
 print_address_description mm/kasan/report.c:377 [inline]
 print_report+0x178/0x518 mm/kasan/report.c:488
 kasan_report+0xd8/0x138 mm/kasan/report.c:601
 __asan_report_load8_noabort+0x20/0x2c mm/kasan/report_generic.c:381
 __skb_unlink include/linux/skbuff.h:2366 [inline]
 __skb_dequeue include/linux/skbuff.h:2385 [inline]
 __skb_queue_purge_reason include/linux/skbuff.h:3175 [inline]
 __skb_queue_purge include/linux/skbuff.h:3181 [inline]
 kcm_release+0x170/0x4c8 net/kcm/kcmsock.c:1691
 __sock_release net/socket.c:659 [inline]
 sock_close+0xa4/0x1e8 net/socket.c:1421
 __fput+0x30c/0x738 fs/file_table.c:376
 ____fput+0x20/0x30 fs/file_table.c:404
 task_work_run+0x230/0x2e0 kernel/task_work.c:180
 exit_task_work include/linux/task_work.h:38 [inline]
 do_exit+0x618/0x1f64 kernel/exit.c:871
 do_group_exit+0x194/0x22c kernel/exit.c:1020
 get_signal+0x1500/0x15ec kernel/signal.c:2893
 do_signal+0x23c/0x3b44 arch/arm64/kernel/signal.c:1249
 do_notify_resume+0x74/0x1f4 arch/arm64/kernel/entry-common.c:148
 exit_to_user_mode_prepare arch/arm64/kernel/entry-common.c:169 [inline]
 exit_to_user_mode arch/arm64/kernel/entry-common.c:178 [inline]
 el0_svc+0xac/0x168 arch/arm64/kernel/entry-common.c:713
 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730
 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598
Allocated by task 6166:
 kasan_save_stack mm/kasan/common.c:47 [inline]
 kasan_save_track+0x40/0x78 mm/kasan/common.c:68
 kasan_save_alloc_info+0x70/0x84 mm/kasan/generic.c:626
 unpoison_slab_object mm/kasan/common.c:314 [inline]
 __kasan_slab_alloc+0x74/0x8c 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_node+0x204/0x4c0 mm/slub.c:3903
 __alloc_skb+0x19c/0x3d8 net/core/skbuff.c:641
 alloc_skb include/linux/skbuff.h:1296 [inline]
 kcm_sendmsg+0x1d3c/0x2124 net/kcm/kcmsock.c:783
 sock_sendmsg_nosec net/socket.c:730 [inline]
 __sock_sendmsg net/socket.c:745 [inline]
 sock_sendmsg+0x220/0x2c0 net/socket.c:768
 splice_to_socket+0x7cc/0xd58 fs/splice.c:889
 do_splice_from fs/splice.c:941 [inline]
 direct_splice_actor+0xec/0x1d8 fs/splice.c:1164
 splice_direct_to_actor+0x438/0xa0c fs/splice.c:1108
 do_splice_direct_actor 
---truncated---
CVE-2024-44942:In the Linux kernel, the following vulnerability has been resolved:
f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GC
syzbot reports a f2fs bug as below:
------------[ cut here ]------------
kernel BUG at fs/f2fs/inline.c:258!
CPU: 1 PID: 34 Comm: kworker/u8:2 Not tainted 6.9.0-rc6-syzkaller-00012-g9e4bc4bcae01 #0
RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258
Call Trace:
 f2fs_write_single_data_page+0xb65/0x1d60 fs/f2fs/data.c:2834
 f2fs_write_cache_pages fs/f2fs/data.c:3133 [inline]
 __f2fs_write_data_pages fs/f2fs/data.c:3288 [inline]
 f2fs_write_data_pages+0x1efe/0x3a90 fs/f2fs/data.c:3315
 do_writepages+0x35b/0x870 mm/page-writeback.c:2612
 __writeback_single_inode+0x165/0x10b0 fs/fs-writeback.c:1650
 writeback_sb_inodes+0x905/0x1260 fs/fs-writeback.c:1941
 wb_writeback+0x457/0xce0 fs/fs-writeback.c:2117
 wb_do_writeback fs/fs-writeback.c:2264 [inline]
 wb_workfn+0x410/0x1090 fs/fs-writeback.c:2304
 process_one_work kernel/workqueue.c:3254 [inline]
 process_scheduled_works+0xa12/0x17c0 kernel/workqueue.c:3335
 worker_thread+0x86d/0xd70 kernel/workqueue.c:3416
 kthread+0x2f2/0x390 kernel/kthread.c:388
 ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
 ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
The root cause is: inline_data inode can be fuzzed, so that there may
be valid blkaddr in its direct node, once f2fs triggers background GC
to migrate the block, it will hit f2fs_bug_on() during dirty page
writeback.
Let's add sanity check on F2FS_INLINE_DATA flag in inode during GC,
so that, it can forbid migrating inline_data inode's data block for
fixing.
CVE-2024-42295:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: handle inconsistent state in nilfs_btnode_create_block()
Syzbot reported that a buffer state inconsistency was detected in
nilfs_btnode_create_block(), triggering a kernel bug.
It is not appropriate to treat this inconsistency as a bug; it can occur
if the argument block address (the buffer index of the newly created
block) is a virtual block number and has been reallocated due to
corruption of the bitmap used to manage its allocation state.
So, modify nilfs_btnode_create_block() and its callers to treat it as a
possible filesystem error, rather than triggering a kernel bug.
CVE-2024-43834:In the Linux kernel, the following vulnerability has been resolved:
xdp: fix invalid wait context of page_pool_destroy()
If the driver uses a page pool, it creates a page pool with
page_pool_create().
The reference count of page pool is 1 as default.
A page pool will be destroyed only when a reference count reaches 0.
page_pool_destroy() is used to destroy page pool, it decreases a
reference count.
When a page pool is destroyed, -&gt;disconnect() is called, which is
mem_allocator_disconnect().
This function internally acquires mutex_lock().
If the driver uses XDP, it registers a memory model with
xdp_rxq_info_reg_mem_model().
The xdp_rxq_info_reg_mem_model() internally increases a page pool
reference count if a memory model is a page pool.
Now the reference count is 2.
To destroy a page pool, the driver should call both page_pool_destroy()
and xdp_unreg_mem_model().
The xdp_unreg_mem_model() internally calls page_pool_destroy().
Only page_pool_destroy() decreases a reference count.
If a driver calls page_pool_destroy() then xdp_unreg_mem_model(), we
will face an invalid wait context warning.
Because xdp_unreg_mem_model() calls page_pool_destroy() with
rcu_read_lock().
The page_pool_destroy() internally acquires mutex_lock().
Splat looks like:
=============================
[ BUG: Invalid wait context ]
6.10.0-rc6+ #4 Tainted: G W
-----------------------------
ethtool/1806 is trying to lock:
ffffffff90387b90 (mem_id_lock){+.+.}-{4:4}, at: mem_allocator_disconnect+0x73/0x150
other info that might help us debug this:
context-{5:5}
3 locks held by ethtool/1806:
stack backtrace:
CPU: 0 PID: 1806 Comm: ethtool Tainted: G W 6.10.0-rc6+ #4 f916f41f172891c800f2fed
Hardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021
Call Trace:
&lt;TASK&gt;
dump_stack_lvl+0x7e/0xc0
__lock_acquire+0x1681/0x4de0
? _printk+0x64/0xe0
? __pfx_mark_lock.part.0+0x10/0x10
? __pfx___lock_acquire+0x10/0x10
lock_acquire+0x1b3/0x580
? mem_allocator_disconnect+0x73/0x150
? __wake_up_klogd.part.0+0x16/0xc0
? __pfx_lock_acquire+0x10/0x10
? dump_stack_lvl+0x91/0xc0
__mutex_lock+0x15c/0x1690
? mem_allocator_disconnect+0x73/0x150
? __pfx_prb_read_valid+0x10/0x10
? mem_allocator_disconnect+0x73/0x150
? __pfx_llist_add_batch+0x10/0x10
? console_unlock+0x193/0x1b0
? lockdep_hardirqs_on+0xbe/0x140
? __pfx___mutex_lock+0x10/0x10
? tick_nohz_tick_stopped+0x16/0x90
? __irq_work_queue_local+0x1e5/0x330
? irq_work_queue+0x39/0x50
? __wake_up_klogd.part.0+0x79/0xc0
? mem_allocator_disconnect+0x73/0x150
mem_allocator_disconnect+0x73/0x150
? __pfx_mem_allocator_disconnect+0x10/0x10
? mark_held_locks+0xa5/0xf0
? rcu_is_watching+0x11/0xb0
page_pool_release+0x36e/0x6d0
page_pool_destroy+0xd7/0x440
xdp_unreg_mem_model+0x1a7/0x2a0
? __pfx_xdp_unreg_mem_model+0x10/0x10
? kfree+0x125/0x370
? bnxt_free_ring.isra.0+0x2eb/0x500
? bnxt_free_mem+0x5ac/0x2500
xdp_rxq_info_unreg+0x4a/0xd0
bnxt_free_mem+0x1356/0x2500
bnxt_close_nic+0xf0/0x3b0
? __pfx_bnxt_close_nic+0x10/0x10
? ethnl_parse_bit+0x2c6/0x6d0
? __pfx___nla_validate_parse+0x10/0x10
? __pfx_ethnl_parse_bit+0x10/0x10
bnxt_set_features+0x2a8/0x3e0
__netdev_update_features+0x4dc/0x1370
? ethnl_parse_bitset+0x4ff/0x750
? __pfx_ethnl_parse_bitset+0x10/0x10
? __pfx___netdev_update_features+0x10/0x10
? mark_held_locks+0xa5/0xf0
? _raw_spin_unlock_irqrestore+0x42/0x70
? __pm_runtime_resume+0x7d/0x110
ethnl_set_features+0x32d/0xa20
To fix this problem, it uses rhashtable_lookup_fast() instead of
rhashtable_lookup() with rcu_read_lock().
Using xa without rcu_read_lock() here is safe.
xa is freed by __xdp_mem_allocator_rcu_free() and this is called by
call_rcu() of mem_xa_remove().
The mem_xa_remove() is called by page_pool_destroy() if a reference
count reaches 0.
The xa is already protected by the reference count mechanism well in the
control plane.
So removing rcu_read_lock() for page_pool_destroy() is safe.
CVE-2024-42259:In the Linux kernel, the following vulnerability has been resolved:
drm/i915/gem: Fix Virtual Memory mapping boundaries calculation
Calculating the size of the mapped area as the lesser value
between the requested size and the actual size does not consider
the partial mapping offset. This can cause page fault access.
Fix the calculation of the starting and ending addresses, the
total size is now deduced from the difference between the end and
start addresses.
Additionally, the calculations have been rewritten in a clearer
and more understandable form.
[Joonas: Add Requires: tag]
Requires: 60a2066c5005 (&quot;drm/i915/gem: Adjust vma offset for framebuffer mmap offset&quot;)
(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)
CVE-2023-45896:ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier's perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.
CVE-2024-43902:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Add null checker before passing variables
Checks null pointer before passing variables to functions.
This fixes 3 NULL_RETURNS issues reported by Coverity.
CVE-2024-44947:In the Linux kernel, the following vulnerability has been resolved:
fuse: Initialize beyond-EOF page contents before setting uptodate
fuse_notify_store(), unlike fuse_do_readpage(), does not enable page
zeroing (because it can be used to change partial page contents).
So fuse_notify_store() must be more careful to fully initialize page
contents (including parts of the page that are beyond end-of-file)
before marking the page uptodate.
The current code can leave beyond-EOF page contents uninitialized, which
makes these uninitialized page contents visible to userspace via mmap().
This is an information leak, but only affects systems which do not
enable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or the
corresponding kernel command line parameter).
CVE-2022-48902:In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not WARN_ON() if we have PageError set
Whenever we do any extent buffer operations we call
assert_eb_page_uptodate() to complain loudly if we're operating on an
non-uptodate page.  Our overnight tests caught this warning earlier this
week
  WARNING: CPU: 1 PID: 553508 at fs/btrfs/extent_io.c:6849 assert_eb_page_uptodate+0x3f/0x50
  CPU: 1 PID: 553508 Comm: kworker/u4:13 Tainted: G        W         5.17.0-rc3+ #564
  Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.13.0-2.fc32 04/01/2014
  Workqueue: btrfs-cache btrfs_work_helper
  RIP: 0010:assert_eb_page_uptodate+0x3f/0x50
  RSP: 0018:ffffa961440a7c68 EFLAGS: 00010246
  RAX: 0017ffffc0002112 RBX: ffffe6e74453f9c0 RCX: 0000000000001000
  RDX: ffffe6e74467c887 RSI: ffffe6e74453f9c0 RDI: ffff8d4c5efc2fc0
  RBP: 0000000000000d56 R08: ffff8d4d4a224000 R09: 0000000000000000
  R10: 00015817fa9d1ef0 R11: 000000000000000c R12: 00000000000007b1
  R13: ffff8d4c5efc2fc0 R14: 0000000001500000 R15: 0000000001cb1000
  FS:  0000000000000000(0000) GS:ffff8d4dbbd00000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007ff31d3448d8 CR3: 0000000118be8004 CR4: 0000000000370ee0
  Call Trace:
   extent_buffer_test_bit+0x3f/0x70
   free_space_test_bit+0xa6/0xc0
   load_free_space_tree+0x1f6/0x470
   caching_thread+0x454/0x630
   ? rcu_read_lock_sched_held+0x12/0x60
   ? rcu_read_lock_sched_held+0x12/0x60
   ? rcu_read_lock_sched_held+0x12/0x60
   ? lock_release+0x1f0/0x2d0
   btrfs_work_helper+0xf2/0x3e0
   ? lock_release+0x1f0/0x2d0
   ? finish_task_switch.isra.0+0xf9/0x3a0
   process_one_work+0x26d/0x580
   ? process_one_work+0x580/0x580
   worker_thread+0x55/0x3b0
   ? process_one_work+0x580/0x580
   kthread+0xf0/0x120
   ? kthread_complete_and_exit+0x20/0x20
   ret_from_fork+0x1f/0x30
This was partially fixed by c2e39305299f01 (&quot;btrfs: clear extent buffer
uptodate when we fail to write it&quot;), however all that fix did was keep
us from finding extent buffers after a failed writeout.  It didn't keep
us from continuing to use a buffer that we already had found.
In this case we're searching the commit root to cache the block group,
so we can start committing the transaction and switch the commit root
and then start writing.  After the switch we can look up an extent
buffer that hasn't been written yet and start processing that block
group.  Then we fail to write that block out and clear Uptodate on the
page, and then we start spewing these errors.
Normally we're protected by the tree lock to a certain degree here.  If
we read a block we have that block read locked, and we block the writer
from locking the block before we submit it for the write.  However this
isn't necessarily fool proof because the read could happen before we do
the submit_bio and after we locked and unlocked the extent buffer.
Also in this particular case we have path-&gt;skip_locking set, so that
won't save us here.  We'll simply get a block that was valid when we
read it, but became invalid while we were using it.
What we really want is to catch the case where we've &quot;read&quot; a block but
it's not marked Uptodate.  On read we ClearPageError(), so if we're
!Uptodate and !Error we know we didn't do the right thing for reading
the page.
Fix this by checking !Uptodate &amp;&amp; !Error, this way we will not complain
if our buffer gets invalidated while we're using it, and we'll maintain
the spirit of the check which is to make sure we have a fully in-cache
block while we're messing with it.
CVE-2022-48901:In the Linux kernel, the following vulnerability has been resolved:
btrfs: do not start relocation until in progress drops are done
We hit a bug with a recovering relocation on mount for one of our file
systems in production.  I reproduced this locally by injecting errors
into snapshot delete with balance running at the same time.  This
presented as an error while looking up an extent item
  WARNING: CPU: 5 PID: 1501 at fs/btrfs/extent-tree.c:866 lookup_inline_extent_backref+0x647/0x680
  CPU: 5 PID: 1501 Comm: btrfs-balance Not tainted 5.16.0-rc8+ #8
  RIP: 0010:lookup_inline_extent_backref+0x647/0x680
  RSP: 0018:ffffae0a023ab960 EFLAGS: 00010202
  RAX: 0000000000000001 RBX: 0000000000000000 RCX: 0000000000000000
  RDX: 0000000000000000 RSI: 000000000000000c RDI: 0000000000000000
  RBP: ffff943fd2a39b60 R08: 0000000000000000 R09: 0000000000000001
  R10: 0001434088152de0 R11: 0000000000000000 R12: 0000000001d05000
  R13: ffff943fd2a39b60 R14: ffff943fdb96f2a0 R15: ffff9442fc923000
  FS:  0000000000000000(0000) GS:ffff944e9eb40000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f1157b1fca8 CR3: 000000010f092000 CR4: 0000000000350ee0
  Call Trace:
   &lt;TASK&gt;
   insert_inline_extent_backref+0x46/0xd0
   __btrfs_inc_extent_ref.isra.0+0x5f/0x200
   ? btrfs_merge_delayed_refs+0x164/0x190
   __btrfs_run_delayed_refs+0x561/0xfa0
   ? btrfs_search_slot+0x7b4/0xb30
   ? btrfs_update_root+0x1a9/0x2c0
   btrfs_run_delayed_refs+0x73/0x1f0
   ? btrfs_update_root+0x1a9/0x2c0
   btrfs_commit_transaction+0x50/0xa50
   ? btrfs_update_reloc_root+0x122/0x220
   prepare_to_merge+0x29f/0x320
   relocate_block_group+0x2b8/0x550
   btrfs_relocate_block_group+0x1a6/0x350
   btrfs_relocate_chunk+0x27/0xe0
   btrfs_balance+0x777/0xe60
   balance_kthread+0x35/0x50
   ? btrfs_balance+0xe60/0xe60
   kthread+0x16b/0x190
   ? set_kthread_struct+0x40/0x40
   ret_from_fork+0x22/0x30
   &lt;/TASK&gt;
Normally snapshot deletion and relocation are excluded from running at
the same time by the fs_info-&gt;cleaner_mutex.  However if we had a
pending balance waiting to get the -&gt;cleaner_mutex, and a snapshot
deletion was running, and then the box crashed, we would come up in a
state where we have a half deleted snapshot.
Again, in the normal case the snapshot deletion needs to complete before
relocation can start, but in this case relocation could very well start
before the snapshot deletion completes, as we simply add the root to the
dead roots list and wait for the next time the cleaner runs to clean up
the snapshot.
Fix this by setting a bit on the fs_info if we have any DEAD_ROOT's that
had a pending drop_progress key.  If they do then we know we were in the
middle of the drop operation and set a flag on the fs_info.  Then
balance can wait until this flag is cleared to start up again.
If there are DEAD_ROOT's that don't have a drop_progress set then we're
safe to start balance right away as we'll be properly protected by the
cleaner_mutex.
CVE-2024-43914:In the Linux kernel, the following vulnerability has been resolved:
md/raid5: avoid BUG_ON() while continue reshape after reassembling
Currently, mdadm support --revert-reshape to abort the reshape while
reassembling, as the test 07revert-grow. However, following BUG_ON()
can be triggerred by the test:
kernel BUG at drivers/md/raid5.c:6278!
invalid opcode: 0000 [#1] PREEMPT SMP PTI
irq event stamp: 158985
CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94
RIP: 0010:reshape_request+0x3f1/0xe60
Call Trace:
 &lt;TASK&gt;
 raid5_sync_request+0x43d/0x550
 md_do_sync+0xb7a/0x2110
 md_thread+0x294/0x2b0
 kthread+0x147/0x1c0
 ret_from_fork+0x59/0x70
 ret_from_fork_asm+0x1a/0x30
 &lt;/TASK&gt;
Root cause is that --revert-reshape update the raid_disks from 5 to 4,
while reshape position is still set, and after reassembling the array,
reshape position will be read from super block, then during reshape the
checking of 'writepos' that is caculated by old reshape position will
fail.
Fix this panic the easy way first, by converting the BUG_ON() to
WARN_ON(), and stop the reshape if checkings fail.
Noted that mdadm must fix --revert-shape as well, and probably md/raid
should enhance metadata validation as well, however this means
reassemble will fail and there must be user tools to fix the wrong
metadata.
CVE-2023-52907:In the Linux kernel, the following vulnerability has been resolved:
nfc: pn533: Wait for out_urb's completion in pn533_usb_send_frame()
Fix a use-after-free that occurs in hcd when in_urb sent from
pn533_usb_send_frame() is completed earlier than out_urb. Its callback
frees the skb data in pn533_send_async_complete() that is used as a
transfer buffer of out_urb. Wait before sending in_urb until the
callback of out_urb is called. To modify the callback of out_urb alone,
separate the complete function of out_urb and ack_urb.
Found by a modified version of syzkaller.
BUG: KASAN: use-after-free in dummy_timer
Call Trace:
 memcpy (mm/kasan/shadow.c:65)
 dummy_perform_transfer (drivers/usb/gadget/udc/dummy_hcd.c:1352)
 transfer (drivers/usb/gadget/udc/dummy_hcd.c:1453)
 dummy_timer (drivers/usb/gadget/udc/dummy_hcd.c:1972)
 arch_static_branch (arch/x86/include/asm/jump_label.h:27)
 static_key_false (include/linux/jump_label.h:207)
 timer_expire_exit (include/trace/events/timer.h:127)
 call_timer_fn (kernel/time/timer.c:1475)
 expire_timers (kernel/time/timer.c:1519)
 __run_timers (kernel/time/timer.c:1790)
 run_timer_softirq (kernel/time/timer.c:1803)
CVE-2024-43899:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Fix null pointer deref in dcn20_resource.c
Fixes a hang thats triggered when MPV is run on a DCN401 dGPU:
mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=all
and then enabling fullscreen playback (double click on the video)
The following calltrace will be seen:
[  181.843989] BUG: kernel NULL pointer dereference, address: 0000000000000000
[  181.843997] #PF: supervisor instruction fetch in kernel mode
[  181.844003] #PF: error_code(0x0010) - not-present page
[  181.844009] PGD 0 P4D 0
[  181.844020] Oops: 0010 [#1] PREEMPT SMP NOPTI
[  181.844028] CPU: 6 PID: 1892 Comm: gnome-shell Tainted: G        W  OE      6.5.0-41-generic #41~22.04.2-Ubuntu
[  181.844038] Hardware name: System manufacturer System Product Name/CROSSHAIR VI HERO, BIOS 6302 10/23/2018
[  181.844044] RIP: 0010:0x0
[  181.844079] Code: Unable to access opcode bytes at 0xffffffffffffffd6.
[  181.844084] RSP: 0018:ffffb593c2b8f7b0 EFLAGS: 00010246
[  181.844093] RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000004
[  181.844099] RDX: ffffb593c2b8f804 RSI: ffffb593c2b8f7e0 RDI: ffff9e3c8e758400
[  181.844105] RBP: ffffb593c2b8f7b8 R08: ffffb593c2b8f9c8 R09: ffffb593c2b8f96c
[  181.844110] R10: 0000000000000000 R11: 0000000000000000 R12: ffffb593c2b8f9c8
[  181.844115] R13: 0000000000000001 R14: ffff9e3c88000000 R15: 0000000000000005
[  181.844121] FS:  00007c6e323bb5c0(0000) GS:ffff9e3f85f80000(0000) knlGS:0000000000000000
[  181.844128] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[  181.844134] CR2: ffffffffffffffd6 CR3: 0000000140fbe000 CR4: 00000000003506e0
[  181.844141] Call Trace:
[  181.844146]  &lt;TASK&gt;
[  181.844153]  ? show_regs+0x6d/0x80
[  181.844167]  ? __die+0x24/0x80
[  181.844179]  ? page_fault_oops+0x99/0x1b0
[  181.844192]  ? do_user_addr_fault+0x31d/0x6b0
[  181.844204]  ? exc_page_fault+0x83/0x1b0
[  181.844216]  ? asm_exc_page_fault+0x27/0x30
[  181.844237]  dcn20_get_dcc_compression_cap+0x23/0x30 [amdgpu]
[  181.845115]  amdgpu_dm_plane_validate_dcc.constprop.0+0xe5/0x180 [amdgpu]
[  181.845985]  amdgpu_dm_plane_fill_plane_buffer_attributes+0x300/0x580 [amdgpu]
[  181.846848]  fill_dc_plane_info_and_addr+0x258/0x350 [amdgpu]
[  181.847734]  fill_dc_plane_attributes+0x162/0x350 [amdgpu]
[  181.848748]  dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[  181.849791]  ? dm_update_plane_state.constprop.0+0x4e3/0x6b0 [amdgpu]
[  181.850840]  amdgpu_dm_atomic_check+0xdfe/0x1760 [amdgpu]
CVE-2024-42276:In the Linux kernel, the following vulnerability has been resolved:
nvme-pci: add missing condition check for existence of mapped data
nvme_map_data() is called when request has physical segments, hence
the nvme_unmap_data() should have same condition to avoid dereference.
CVE-2024-42311:In the Linux kernel, the following vulnerability has been resolved:
hfs: fix to initialize fields of hfs_inode_info after hfs_alloc_inode()
Syzbot reports uninitialized value access issue as below:
loop0: detected capacity change from 0 to 64
=====================================================
BUG: KMSAN: uninit-value in hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30
 hfs_revalidate_dentry+0x307/0x3f0 fs/hfs/sysdep.c:30
 d_revalidate fs/namei.c:862 [inline]
 lookup_fast+0x89e/0x8e0 fs/namei.c:1649
 walk_component fs/namei.c:2001 [inline]
 link_path_walk+0x817/0x1480 fs/namei.c:2332
 path_lookupat+0xd9/0x6f0 fs/namei.c:2485
 filename_lookup+0x22e/0x740 fs/namei.c:2515
 user_path_at_empty+0x8b/0x390 fs/namei.c:2924
 user_path_at include/linux/namei.h:57 [inline]
 do_mount fs/namespace.c:3689 [inline]
 __do_sys_mount fs/namespace.c:3898 [inline]
 __se_sys_mount+0x66b/0x810 fs/namespace.c:3875
 __x64_sys_mount+0xe4/0x140 fs/namespace.c:3875
 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
BUG: KMSAN: uninit-value in hfs_ext_read_extent fs/hfs/extent.c:196 [inline]
BUG: KMSAN: uninit-value in hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366
 hfs_ext_read_extent fs/hfs/extent.c:196 [inline]
 hfs_get_block+0x92d/0x1620 fs/hfs/extent.c:366
 block_read_full_folio+0x4ff/0x11b0 fs/buffer.c:2271
 hfs_read_folio+0x55/0x60 fs/hfs/inode.c:39
 filemap_read_folio+0x148/0x4f0 mm/filemap.c:2426
 do_read_cache_folio+0x7c8/0xd90 mm/filemap.c:3553
 do_read_cache_page mm/filemap.c:3595 [inline]
 read_cache_page+0xfb/0x2f0 mm/filemap.c:3604
 read_mapping_page include/linux/pagemap.h:755 [inline]
 hfs_btree_open+0x928/0x1ae0 fs/hfs/btree.c:78
 hfs_mdb_get+0x260c/0x3000 fs/hfs/mdb.c:204
 hfs_fill_super+0x1fb1/0x2790 fs/hfs/super.c:406
 mount_bdev+0x628/0x920 fs/super.c:1359
 hfs_mount+0xcd/0xe0 fs/hfs/super.c:456
 legacy_get_tree+0x167/0x2e0 fs/fs_context.c:610
 vfs_get_tree+0xdc/0x5d0 fs/super.c:1489
 do_new_mount+0x7a9/0x16f0 fs/namespace.c:3145
 path_mount+0xf98/0x26a0 fs/namespace.c:3475
 do_mount fs/namespace.c:3488 [inline]
 __do_sys_mount fs/namespace.c:3697 [inline]
 __se_sys_mount+0x919/0x9e0 fs/namespace.c:3674
 __ia32_sys_mount+0x15b/0x1b0 fs/namespace.c:3674
 do_syscall_32_irqs_on arch/x86/entry/common.c:112 [inline]
 __do_fast_syscall_32+0xa2/0x100 arch/x86/entry/common.c:178
 do_fast_syscall_32+0x37/0x80 arch/x86/entry/common.c:203
 do_SYSENTER_32+0x1f/0x30 arch/x86/entry/common.c:246
 entry_SYSENTER_compat_after_hwframe+0x70/0x82
Uninit was created at:
 __alloc_pages+0x9a6/0xe00 mm/page_alloc.c:4590
 __alloc_pages_node include/linux/gfp.h:238 [inline]
 alloc_pages_node include/linux/gfp.h:261 [inline]
 alloc_slab_page mm/slub.c:2190 [inline]
 allocate_slab mm/slub.c:2354 [inline]
 new_slab+0x2d7/0x1400 mm/slub.c:2407
 ___slab_alloc+0x16b5/0x3970 mm/slub.c:3540
 __slab_alloc mm/slub.c:3625 [inline]
 __slab_alloc_node mm/slub.c:3678 [inline]
 slab_alloc_node mm/slub.c:3850 [inline]
 kmem_cache_alloc_lru+0x64d/0xb30 mm/slub.c:3879
 alloc_inode_sb include/linux/fs.h:3018 [inline]
 hfs_alloc_inode+0x5a/0xc0 fs/hfs/super.c:165
 alloc_inode+0x83/0x440 fs/inode.c:260
 new_inode_pseudo fs/inode.c:1005 [inline]
 new_inode+0x38/0x4f0 fs/inode.c:1031
 hfs_new_inode+0x61/0x1010 fs/hfs/inode.c:186
 hfs_mkdir+0x54/0x250 fs/hfs/dir.c:228
 vfs_mkdir+0x49a/0x700 fs/namei.c:4126
 do_mkdirat+0x529/0x810 fs/namei.c:4149
 __do_sys_mkdirat fs/namei.c:4164 [inline]
 __se_sys_mkdirat fs/namei.c:4162 [inline]
 __x64_sys_mkdirat+0xc8/0x120 fs/namei.c:4162
 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
It missed to initialize .tz_secondswest, .cached_start and .cached_blocks
fields in struct hfs_inode_info after hfs_alloc_inode(), fix it.
CVE-2024-44960:In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: core: Check for unset descriptor
Make sure the descriptor has been set before looking at maxpacket.
This fixes a null pointer panic in this case.
This may happen if the gadget doesn't properly set up the endpoint
for the current speed, or the gadget descriptors are malformed and
the descriptor for the speed/endpoint are not found.
No current gadget driver is known to have this problem, but this
may cause a hard-to-find bug during development of new gadgets.
CVE-2024-44971:In the Linux kernel, the following vulnerability has been resolved:
net: dsa: bcm_sf2: Fix a possible memory leak in bcm_sf2_mdio_register()
bcm_sf2_mdio_register() calls of_phy_find_device() and then
phy_device_remove() in a loop to remove existing PHY devices.
of_phy_find_device() eventually calls bus_find_device(), which calls
get_device() on the returned struct device * to increment the refcount.
The current implementation does not decrement the refcount, which causes
memory leak.
This commit adds the missing phy_device_free() call to decrement the
refcount via put_device() to balance the refcount.
CVE-2023-52916:In the Linux kernel, the following vulnerability has been resolved:
media: aspeed: Fix memory overwrite if timing is 1600x900
When capturing 1600x900, system could crash when system memory usage is
tight.
The way to reproduce this issue:
1. Use 1600x900 to display on host
2. Mount ISO through 'Virtual media' on OpenBMC's web
3. Run script as below on host to do sha continuously
  #!/bin/bash
  while [ [1] ];
  do
	find /media -type f -printf '&quot;%h/%f&quot;\n' | xargs sha256sum
  done
4. Open KVM on OpenBMC's web
The size of macro block captured is 8x8. Therefore, we should make sure
the height of src-buf is 8 aligned to fix this issue.
CVE-2024-43829:In the Linux kernel, the following vulnerability has been resolved:
drm/qxl: Add check for drm_cvt_mode
Add check for the return value of drm_cvt_mode() and return the error if
it fails in order to avoid NULL pointer dereference.
CVE-2024-36934:In the Linux kernel, the following vulnerability has been resolved:
bna: ensure the copied buf is NUL terminated
Currently, we allocate a nbytes-sized kernel buffer and copy nbytes 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-2022-48887:In the Linux kernel, the following vulnerability has been resolved:
drm/vmwgfx: Remove rcu locks from user resources
User resource lookups used rcu to avoid two extra atomics. Unfortunately
the rcu paths were buggy and it was easy to make the driver crash by
submitting command buffers from two different threads. Because the
lookups never show up in performance profiles replace them with a
regular spin lock which fixes the races in accesses to those shared
resources.
Fixes kernel oops'es in IGT's vmwgfx execution_buffer stress test and
seen crashes with apps using shared resources.
CVE-2024-44948:In the Linux kernel, the following vulnerability has been resolved:
x86/mtrr: Check if fixed MTRRs exist before saving them
MTRRs have an obsolete fixed variant for fine grained caching control
of the 640K-1MB region that uses separate MSRs. This fixed variant has
a separate capability bit in the MTRR capability MSR.
So far all x86 CPUs which support MTRR have this separate bit set, so it
went unnoticed that mtrr_save_state() does not check the capability bit
before accessing the fixed MTRR MSRs.
Though on a CPU that does not support the fixed MTRR capability this
results in a #GP.  The #GP itself is harmless because the RDMSR fault is
handled gracefully, but results in a WARN_ON().
Add the missing capability check to prevent this.
CVE-2024-44988:In the Linux kernel, the following vulnerability has been resolved:
net: dsa: mv88e6xxx: Fix out-of-bound access
If an ATU violation was caused by a CPU Load operation, the SPID could
be larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).
CVE-2024-44986:In the Linux kernel, the following vulnerability has been resolved:
ipv6: fix possible UAF in ip6_finish_output2()
If skb_expand_head() returns NULL, skb has been freed
and associated dst/idev could also have been freed.
We need to hold rcu_read_lock() to make sure the dst and
associated idev are alive.
CVE-2024-44987:In the Linux kernel, the following vulnerability has been resolved:
ipv6: prevent UAF in ip6_send_skb()
syzbot reported an UAF in ip6_send_skb() [1]
After ip6_local_out() has returned, we no longer can safely
dereference rt, unless we hold rcu_read_lock().
A similar issue has been fixed in commit
a688caa34beb (&quot;ipv6: take rcu lock in rawv6_send_hdrinc()&quot;)
Another potential issue in ip6_finish_output2() is handled in a
separate patch.
[1]
 BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530
CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024
Call Trace:
 &lt;TASK&gt;
  __dump_stack lib/dump_stack.c:93 [inline]
  dump_stack_lvl+0x241/0x360 lib/dump_stack.c:119
  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
  ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964
  rawv6_push_pending_frames+0x75c/0x9e0 net/ipv6/raw.c:588
  rawv6_sendmsg+0x19c7/0x23c0 net/ipv6/raw.c:926
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  sock_write_iter+0x2dd/0x400 net/socket.c:1160
 do_iter_readv_writev+0x60a/0x890
  vfs_writev+0x37c/0xbb0 fs/read_write.c:971
  do_writev+0x1b1/0x350 fs/read_write.c:1018
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
RIP: 0033:0x7f936bf79e79
Code: ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 40 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 a8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014
RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79
RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004
RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 00007f936c115f80 R15: 00007fff2860a7a8
 &lt;/TASK&gt;
Allocated by task 6530:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  unpoison_slab_object mm/kasan/common.c:312 [inline]
  __kasan_slab_alloc+0x66/0x80 mm/kasan/common.c:338
  kasan_slab_alloc include/linux/kasan.h:201 [inline]
  slab_post_alloc_hook mm/slub.c:3988 [inline]
  slab_alloc_node mm/slub.c:4037 [inline]
  kmem_cache_alloc_noprof+0x135/0x2a0 mm/slub.c:4044
  dst_alloc+0x12b/0x190 net/core/dst.c:89
  ip6_blackhole_route+0x59/0x340 net/ipv6/route.c:2670
  make_blackhole net/xfrm/xfrm_policy.c:3120 [inline]
  xfrm_lookup_route+0xd1/0x1c0 net/xfrm/xfrm_policy.c:3313
  ip6_dst_lookup_flow+0x13e/0x180 net/ipv6/ip6_output.c:1257
  rawv6_sendmsg+0x1283/0x23c0 net/ipv6/raw.c:898
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x1a6/0x270 net/socket.c:745
  ____sys_sendmsg+0x525/0x7d0 net/socket.c:2597
  ___sys_sendmsg net/socket.c:2651 [inline]
  __sys_sendmsg+0x2b0/0x3a0 net/socket.c:2680
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xf3/0x230 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Freed by task 45:
  kasan_save_stack mm/kasan/common.c:47 [inline]
  kasan_save_track+0x3f/0x80 mm/kasan/common.c:68
  kasan_save_free_info+0x40/0x50 mm/kasan/generic.c:579
  poison_slab_object+0xe0/0x150 mm/kasan/common.c:240
  __kasan_slab_free+0x37/0x60 mm/kasan/common.c:256
  kasan_slab_free include/linux/kasan.h:184 [inline]
  slab_free_hook mm/slub.c:2252 [inline]
  slab_free mm/slub.c:4473 [inline]
  kmem_cache_free+0x145/0x350 mm/slub.c:4548
  dst_destroy+0x2ac/0x460 net/core/dst.c:124
  rcu_do_batch kernel/rcu/tree.c:2569 [inline]
  rcu_core+0xafd/0x1830 kernel/rcu/tree.
---truncated---
CVE-2023-52915:In the Linux kernel, the following vulnerability has been resolved:
media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xfer
In af9035_i2c_master_xfer, msg is controlled by user. When msg[i].buf
is null and msg[i].len is zero, former checks on msg[i].buf would be
passed. Malicious data finally reach af9035_i2c_master_xfer. If accessing
msg[i].buf[0] without sanity check, null ptr deref would happen.
We add check on msg[i].len to prevent crash.
Similar commit:
commit 0ed554fd769a
(&quot;media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()&quot;)
CVE-2023-52894:In the Linux kernel, the following vulnerability has been resolved:
usb: gadget: f_ncm: fix potential NULL ptr deref in ncm_bitrate()
In Google internal bug 265639009 we've received an (as yet) unreproducible
crash report from an aarch64 GKI 5.10.149-android13 running device.
AFAICT the source code is at:
  https://android.googlesource.com/kernel/common/+/refs/tags/ASB-2022-12-05_13-5.10
The call stack is:
  ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()
with the crash at:
  ncm_do_notify+0x98/0x270
Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)
Which I believe disassembles to (I don't know ARM assembly, but it looks sane enough to me...):
  // halfword (16-bit) store presumably to event-&gt;wLength (at offset 6 of struct usb_cdc_notification)
  0B 0D 00 79    strh w11, [x8, #6]
  // word (32-bit) store presumably to req-&gt;Length (at offset 8 of struct usb_request)
  6C 0A 00 B9    str  w12, [x19, #8]
  // x10 (NULL) was read here from offset 0 of valid pointer x9
  // IMHO we're reading 'cdev-&gt;gadget' and getting NULL
  // gadget is indeed at offset 0 of struct usb_composite_dev
  2A 01 40 F9    ldr  x10, [x9]
  // loading req-&gt;buf pointer, which is at offset 0 of struct usb_request
  69 02 40 F9    ldr  x9, [x19]
  // x10 is null, crash, appears to be attempt to read cdev-&gt;gadget-&gt;max_speed
  4B 5D 40 B9    ldr  w11, [x10, #0x5c]
which seems to line up with ncm_do_notify() case NCM_NOTIFY_SPEED code fragment:
  event-&gt;wLength = cpu_to_le16(8);
  req-&gt;length = NCM_STATUS_BYTECOUNT;
  /* SPEED_CHANGE data is up/down speeds in bits/sec */
  data = req-&gt;buf + sizeof *event;
  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));
My analysis of registers and NULL ptr deref crash offset
  (Unable to handle kernel NULL pointer dereference at virtual address 000000000000005c)
heavily suggests that the crash is due to 'cdev-&gt;gadget' being NULL when executing:
  data[0] = cpu_to_le32(ncm_bitrate(cdev-&gt;gadget));
which calls:
  ncm_bitrate(NULL)
which then calls:
  gadget_is_superspeed(NULL)
which reads
  ((struct usb_gadget *)NULL)-&gt;max_speed
and hits a panic.
AFAICT, if I'm counting right, the offset of max_speed is indeed 0x5C.
(remember there's a GKI KABI reservation of 16 bytes in struct work_struct)
It's not at all clear to me how this is all supposed to work...
but returning 0 seems much better than panic-ing...
CVE-2022-48828:In the Linux kernel, the following vulnerability has been resolved:
NFSD: Fix ia_size underflow
iattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 and
NFSv4 both define file size as an unsigned 64-bit type. Thus there
is a range of valid file size values an NFS client can send that is
already larger than Linux can handle.
Currently decode_fattr4() dumps a full u64 value into ia_size. If
that value happens to be larger than S64_MAX, then ia_size
underflows. I'm about to fix up the NFSv3 behavior as well, so let's
catch the underflow in the common code path: nfsd_setattr().
CVE-2023-52900:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix general protection fault in nilfs_btree_insert()
If nilfs2 reads a corrupted disk image and tries to reads a b-tree node
block by calling __nilfs_btree_get_block() against an invalid virtual
block address, it returns -ENOENT because conversion of the virtual block
address to a disk block address fails.  However, this return value is the
same as the internal code that b-tree lookup routines return to indicate
that the block being searched does not exist, so functions that operate on
that b-tree may misbehave.
When nilfs_btree_insert() receives this spurious 'not found' code from
nilfs_btree_do_lookup(), it misunderstands that the 'not found' check was
successful and continues the insert operation using incomplete lookup path
data, causing the following crash:
 general protection fault, probably for non-canonical address
 0xdffffc0000000005: 0000 [#1] PREEMPT SMP KASAN
 KASAN: null-ptr-deref in range [0x0000000000000028-0x000000000000002f]
 ...
 RIP: 0010:nilfs_btree_get_nonroot_node fs/nilfs2/btree.c:418 [inline]
 RIP: 0010:nilfs_btree_prepare_insert fs/nilfs2/btree.c:1077 [inline]
 RIP: 0010:nilfs_btree_insert+0x6d3/0x1c10 fs/nilfs2/btree.c:1238
 Code: bc 24 80 00 00 00 4c 89 f8 48 c1 e8 03 42 80 3c 28 00 74 08 4c 89
 ff e8 4b 02 92 fe 4d 8b 3f 49 83 c7 28 4c 89 f8 48 c1 e8 03 &lt;42&gt; 80 3c
 28 00 74 08 4c 89 ff e8 2e 02 92 fe 4d 8b 3f 49 83 c7 02
 ...
 Call Trace:
 &lt;TASK&gt;
  nilfs_bmap_do_insert fs/nilfs2/bmap.c:121 [inline]
  nilfs_bmap_insert+0x20d/0x360 fs/nilfs2/bmap.c:147
  nilfs_get_block+0x414/0x8d0 fs/nilfs2/inode.c:101
  __block_write_begin_int+0x54c/0x1a80 fs/buffer.c:1991
  __block_write_begin fs/buffer.c:2041 [inline]
  block_write_begin+0x93/0x1e0 fs/buffer.c:2102
  nilfs_write_begin+0x9c/0x110 fs/nilfs2/inode.c:261
  generic_perform_write+0x2e4/0x5e0 mm/filemap.c:3772
  __generic_file_write_iter+0x176/0x400 mm/filemap.c:3900
  generic_file_write_iter+0xab/0x310 mm/filemap.c:3932
  call_write_iter include/linux/fs.h:2186 [inline]
  new_sync_write fs/read_write.c:491 [inline]
  vfs_write+0x7dc/0xc50 fs/read_write.c:584
  ksys_write+0x177/0x2a0 fs/read_write.c:637
  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
 ...
 &lt;/TASK&gt;
This patch fixes the root cause of this problem by replacing the error
code that __nilfs_btree_get_block() returns on block address conversion
failure from -ENOENT to another internal code -EINVAL which means that the
b-tree metadata is corrupted.
By returning -EINVAL, it propagates without glitches, and for all relevant
b-tree operations, functions in the upper bmap layer output an error
message indicating corrupted b-tree metadata via
nilfs_bmap_convert_error(), and code -EIO will be eventually returned as
it should be.
CVE-2024-42104:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: add missing check for inode numbers on directory entries
Syzbot reported that mounting and unmounting a specific pattern of
corrupted nilfs2 filesystem images causes a use-after-free of metadata
file inodes, which triggers a kernel bug in lru_add_fn().
As Jan Kara pointed out, this is because the link count of a metadata file
gets corrupted to 0, and nilfs_evict_inode(), which is called from iput(),
tries to delete that inode (ifile inode in this case).
The inconsistency occurs because directories containing the inode numbers
of these metadata files that should not be visible in the namespace are
read without checking.
Fix this issue by treating the inode numbers of these internal files as
errors in the sanity check helper when reading directory folios/pages.
Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layer
analysis.
CVE-2024-41059:In the Linux kernel, the following vulnerability has been resolved:
hfsplus: fix uninit-value in copy_name
[syzbot reported]
BUG: KMSAN: uninit-value in sized_strscpy+0xc4/0x160
 sized_strscpy+0xc4/0x160
 copy_name+0x2af/0x320 fs/hfsplus/xattr.c:411
 hfsplus_listxattr+0x11e9/0x1a50 fs/hfsplus/xattr.c:750
 vfs_listxattr fs/xattr.c:493 [inline]
 listxattr+0x1f3/0x6b0 fs/xattr.c:840
 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
 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:
 slab_post_alloc_hook mm/slub.c:3877 [inline]
 slab_alloc_node mm/slub.c:3918 [inline]
 kmalloc_trace+0x57b/0xbe0 mm/slub.c:4065
 kmalloc include/linux/slab.h:628 [inline]
 hfsplus_listxattr+0x4cc/0x1a50 fs/hfsplus/xattr.c:699
 vfs_listxattr fs/xattr.c:493 [inline]
 listxattr+0x1f3/0x6b0 fs/xattr.c:840
 path_listxattr fs/xattr.c:864 [inline]
 __do_sys_listxattr fs/xattr.c:876 [inline]
 __se_sys_listxattr fs/xattr.c:873 [inline]
 __x64_sys_listxattr+0x16b/0x2f0 fs/xattr.c:873
 x64_sys_call+0x2ba0/0x3b50 arch/x86/include/generated/asm/syscalls_64.h:195
 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
[Fix]
When allocating memory to strbuf, initialize memory to 0.
CVE-2024-42292:In the Linux kernel, the following vulnerability has been resolved:
kobject_uevent: Fix OOB access within zap_modalias_env()
zap_modalias_env() wrongly calculates size of memory block to move, so
will cause OOB memory access issue if variable MODALIAS is not the last
one within its @env parameter, fixed by correcting size to memmove.
CVE-2024-41017:In the Linux kernel, the following vulnerability has been resolved:
jfs: don't walk off the end of ealist
Add a check before visiting the members of ea to
make sure each ea stays within the ealist.
CVE-2024-42119:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip finding free audio for unknown engine_id
[WHY]
ENGINE_ID_UNKNOWN = -1 and can not be used as an array index. Plus, it
also means it is uninitialized and does not need free audio.
[HOW]
Skip and return NULL.
This fixes 2 OVERRUN issues reported by Coverity.
CVE-2024-36915:In the Linux kernel, the following vulnerability has been resolved:
nfc: llcp: fix nfc_llcp_setsockopt() unsafe copies
syzbot reported unsafe calls to copy_from_sockptr() [1]
Use copy_safe_from_sockptr() instead.
[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 nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078
CPU: 0 PID: 5078 Comm: syz-executor459 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]
  nfc_llcp_setsockopt+0x6c2/0x850 net/nfc/llcp_sock.c:255
  do_sock_setsockopt+0x3b1/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+0xfd/0x240
 entry_SYSCALL_64_after_hwframe+0x6d/0x75
RIP: 0033:0x7f7fac07fd89
Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 18 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b8 ff ff ff f7 d8 64 89 01 48
RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036
RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89
RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004
RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000
R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000
R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
CVE-2024-44999:In the Linux kernel, the following vulnerability has been resolved:
gtp: pull network headers in gtp_dev_xmit()
syzbot/KMSAN reported use of uninit-value in get_dev_xmit() [1]
We must make sure the IPv4 or Ipv6 header is pulled in skb-&gt;head
before accessing fields in them.
Use pskb_inet_may_pull() to fix this issue.
[1]
BUG: KMSAN: uninit-value in ipv6_pdp_find drivers/net/gtp.c:220 [inline]
 BUG: KMSAN: uninit-value in gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
 BUG: KMSAN: uninit-value in gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
  ipv6_pdp_find drivers/net/gtp.c:220 [inline]
  gtp_build_skb_ip6 drivers/net/gtp.c:1229 [inline]
  gtp_dev_xmit+0x1424/0x2540 drivers/net/gtp.c:1281
  __netdev_start_xmit include/linux/netdevice.h:4913 [inline]
  netdev_start_xmit include/linux/netdevice.h:4922 [inline]
  xmit_one net/core/dev.c:3580 [inline]
  dev_hard_start_xmit+0x247/0xa20 net/core/dev.c:3596
  __dev_queue_xmit+0x358c/0x5610 net/core/dev.c:4423
  dev_queue_xmit include/linux/netdevice.h:3105 [inline]
  packet_xmit+0x9c/0x6c0 net/packet/af_packet.c:276
  packet_snd net/packet/af_packet.c:3145 [inline]
  packet_sendmsg+0x90e3/0xa3a0 net/packet/af_packet.c:3177
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2204
  __do_sys_sendto net/socket.c:2216 [inline]
  __se_sys_sendto net/socket.c:2212 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
Uninit was created at:
  slab_post_alloc_hook mm/slub.c:3994 [inline]
  slab_alloc_node mm/slub.c:4037 [inline]
  kmem_cache_alloc_node_noprof+0x6bf/0xb80 mm/slub.c:4080
  kmalloc_reserve+0x13d/0x4a0 net/core/skbuff.c:583
  __alloc_skb+0x363/0x7b0 net/core/skbuff.c:674
  alloc_skb include/linux/skbuff.h:1320 [inline]
  alloc_skb_with_frags+0xc8/0xbf0 net/core/skbuff.c:6526
  sock_alloc_send_pskb+0xa81/0xbf0 net/core/sock.c:2815
  packet_alloc_skb net/packet/af_packet.c:2994 [inline]
  packet_snd net/packet/af_packet.c:3088 [inline]
  packet_sendmsg+0x749c/0xa3a0 net/packet/af_packet.c:3177
  sock_sendmsg_nosec net/socket.c:730 [inline]
  __sock_sendmsg+0x30f/0x380 net/socket.c:745
  __sys_sendto+0x685/0x830 net/socket.c:2204
  __do_sys_sendto net/socket.c:2216 [inline]
  __se_sys_sendto net/socket.c:2212 [inline]
  __x64_sys_sendto+0x125/0x1d0 net/socket.c:2212
  x64_sys_call+0x3799/0x3c10 arch/x86/include/generated/asm/syscalls_64.h:45
  do_syscall_x64 arch/x86/entry/common.c:52 [inline]
  do_syscall_64+0xcd/0x1e0 arch/x86/entry/common.c:83
 entry_SYSCALL_64_after_hwframe+0x77/0x7f
CPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024
CVE-2024-44974:In the Linux kernel, the following vulnerability has been resolved:
mptcp: pm: avoid possible UaF when selecting endp
select_local_address() and select_signal_address() both select an
endpoint entry from the list inside an RCU protected section, but return
a reference to it, to be read later on. If the entry is dereferenced
after the RCU unlock, reading info could cause a Use-after-Free.
A simple solution is to copy the required info while inside the RCU
protected section to avoid any risk of UaF later. The address ID might
need to be modified later to handle the ID0 case later, so a copy seems
OK to deal with.
CVE-2024-45003:In the Linux kernel, the following vulnerability has been resolved:
vfs: Don't evict inode under the inode lru traversing context
The inode reclaiming process(See function prune_icache_sb) collects all
reclaimable inodes and mark them with I_FREEING flag at first, at that
time, other processes will be stuck if they try getting these inodes
(See function find_inode_fast), then the reclaiming process destroy the
inodes by function dispose_list(). Some filesystems(eg. ext4 with
ea_inode feature, ubifs with xattr) may do inode lookup in the inode
evicting callback function, if the inode lookup is operated under the
inode lru traversing context, deadlock problems may happen.
Case 1: In function ext4_evict_inode(), the ea inode lookup could happen
        if ea_inode feature is enabled, the lookup process will be stuck
	under the evicting context like this:
 1. File A has inode i_reg and an ea inode i_ea
 2. getfattr(A, xattr_buf) // i_ea is added into lru // lru-&gt;i_ea
 3. Then, following three processes running like this:
    PA                              PB
 echo 2 &gt; /proc/sys/vm/drop_caches
  shrink_slab
   prune_dcache_sb
   // i_reg is added into lru, lru-&gt;i_ea-&gt;i_reg
   prune_icache_sb
    list_lru_walk_one
     inode_lru_isolate
      i_ea-&gt;i_state |= I_FREEING // set inode state
     inode_lru_isolate
      __iget(i_reg)
      spin_unlock(&amp;i_reg-&gt;i_lock)
      spin_unlock(lru_lock)
                                     rm file A
                                      i_reg-&gt;nlink = 0
      iput(i_reg) // i_reg-&gt;nlink is 0, do evict
       ext4_evict_inode
        ext4_xattr_delete_inode
         ext4_xattr_inode_dec_ref_all
          ext4_xattr_inode_iget
           ext4_iget(i_ea-&gt;i_ino)
            iget_locked
             find_inode_fast
              __wait_on_freeing_inode(i_ea) ----? AA deadlock
    dispose_list // cannot be executed by prune_icache_sb
     wake_up_bit(&amp;i_ea-&gt;i_state)
Case 2: In deleted inode writing function ubifs_jnl_write_inode(), file
        deleting process holds BASEHD's wbuf-&gt;io_mutex while getting the
	xattr inode, which could race with inode reclaiming process(The
        reclaiming process could try locking BASEHD's wbuf-&gt;io_mutex in
	inode evicting function), then an ABBA deadlock problem would
	happen as following:
 1. File A has inode ia and a xattr(with inode ixa), regular file B has
    inode ib and a xattr.
 2. getfattr(A, xattr_buf) // ixa is added into lru // lru-&gt;ixa
 3. Then, following three processes running like this:
        PA                PB                        PC
                echo 2 &gt; /proc/sys/vm/drop_caches
                 shrink_slab
                  prune_dcache_sb
                  // ib and ia are added into lru, lru-&gt;ixa-&gt;ib-&gt;ia
                  prune_icache_sb
                   list_lru_walk_one
                    inode_lru_isolate
                     ixa-&gt;i_state |= I_FREEING // set inode state
                    inode_lru_isolate
                     __iget(ib)
                     spin_unlock(&amp;ib-&gt;i_lock)
                     spin_unlock(lru_lock)
                                                   rm file B
                                                    ib-&gt;nlink = 0
 rm file A
  iput(ia)
   ubifs_evict_inode(ia)
    ubifs_jnl_delete_inode(ia)
     ubifs_jnl_write_inode(ia)
      make_reservation(BASEHD) // Lock wbuf-&gt;io_mutex
      ubifs_iget(ixa-&gt;i_ino)
       iget_locked
        find_inode_fast
         __wait_on_freeing_inode(ixa)
          |          iput(ib) // ib-&gt;nlink is 0, do evict
          |           ubifs_evict_inode
          |            ubifs_jnl_delete_inode(ib)
          ?             ubifs_jnl_write_inode
     ABBA deadlock ?-----make_reservation(BASEHD)
                   dispose_list // cannot be executed by prune_icache_sb
                    wake_up_bit(&amp;ixa-&gt;i_state)
Fix the possible deadlock by using new inode state flag I_LRU_ISOLATING
to pin the inode in memory while inode_lru_isolate(
---truncated---
CVE-2024-46745:In the Linux kernel, the following vulnerability has been resolved:
Input: uinput - reject requests with unreasonable number of slots
When exercising uinput interface syzkaller may try setting up device
with a really large number of slots, which causes memory allocation
failure in input_mt_init_slots(). While this allocation failure is
handled properly and request is rejected, it results in syzkaller
reports. Additionally, such request may put undue burden on the
system which will try to free a lot of memory for a bogus request.
Fix it by limiting allowed number of slots to 100. This can easily
be extended if we see devices that can track more than 100 contacts.
CVE-2024-45028:In the Linux kernel, the following vulnerability has been resolved:
mmc: mmc_test: Fix NULL dereference on allocation failure
If the &quot;test-&gt;highmem = alloc_pages()&quot; allocation fails then calling
__free_pages(test-&gt;highmem) will result in a NULL dereference.  Also
change the error code to -ENOMEM instead of returning success.
CVE-2024-46723:In the Linux kernel, the following vulnerability has been resolved:
drm/amdgpu: fix ucode out-of-bounds read warning
Clear warning that read ucode[] may out-of-bounds.
CVE-2024-36270:In the Linux kernel, the following vulnerability has been resolved:
netfilter: tproxy: bail out if IP has been disabled on the device
syzbot reports:
general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTI
KASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f]
[..]
RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62
Call Trace:
 nft_tproxy_eval_v4 net/netfilter/nft_tproxy.c:56 [inline]
 nft_tproxy_eval+0xa9a/0x1a00 net/netfilter/nft_tproxy.c:168
__in_dev_get_rcu() can return NULL, so check for this.
CVE-2024-46747:In the Linux kernel, the following vulnerability has been resolved:
HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixup
report_fixup for the Cougar 500k Gaming Keyboard was not verifying
that the report descriptor size was correct before accessing it
CVE-2024-44995:In the Linux kernel, the following vulnerability has been resolved:
net: hns3: fix a deadlock problem when config TC during resetting
When config TC during the reset process, may cause a deadlock, the flow is
as below:
                             pf reset start
                                 │
                                 ▼
                              ......
setup tc                         │
    │                            ▼
    ▼                      DOWN: napi_disable()
napi_disable()(skip)             │
    │                            │
    ▼                            ▼
  ......                      ......
    │                            │
    ▼                            │
napi_enable()                    │
                                 ▼
                           UINIT: netif_napi_del()
                                 │
                                 ▼
                              ......
                                 │
                                 ▼
                           INIT: netif_napi_add()
                                 │
                                 ▼
                              ......                 global reset start
                                 │                      │
                                 ▼                      ▼
                           UP: napi_enable()(skip)    ......
                                 │                      │
                                 ▼                      ▼
                              ......                 napi_disable()
In reset process, the driver will DOWN the port and then UINIT, in this
case, the setup tc process will UP the port before UINIT, so cause the
problem. Adds a DOWN process in UINIT to fix it.
CVE-2024-46714:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/display: Skip wbscl_set_scaler_filter if filter is null
Callers can pass null in filter (i.e. from returned from the function
wbscl_get_filter_coeffs_16p) and a null check is added to ensure that is
not the case.
This fixes 4 NULL_RETURNS issues reported by Coverity.
CVE-2024-46731:In the Linux kernel, the following vulnerability has been resolved:
drm/amd/pm: fix the Out-of-bounds read warning
using index i - 1U may beyond element index
for mc_data[] when i = 0.
CVE-2024-44965:In the Linux kernel, the following vulnerability has been resolved:
x86/mm: Fix pti_clone_pgtable() alignment assumption
Guenter reported dodgy crashes on an i386-nosmp build using GCC-11
that had the form of endless traps until entry stack exhaust and then
#DF from the stack guard.
It turned out that pti_clone_pgtable() had alignment assumptions on
the start address, notably it hard assumes start is PMD aligned. This
is true on x86_64, but very much not true on i386.
These assumptions can cause the end condition to malfunction, leading
to a 'short' clone. Guess what happens when the user mapping has a
short copy of the entry text?
Use the correct increment form for addr to avoid alignment
assumptions.
CVE-2024-46787:In the Linux kernel, the following vulnerability has been resolved:
userfaultfd: fix checks for huge PMDs
Patch series &quot;userfaultfd: fix races around pmd_trans_huge() check&quot;, v2.
The pmd_trans_huge() code in mfill_atomic() is wrong in three different
ways depending on kernel version:
1. The pmd_trans_huge() check is racy and can lead to a BUG_ON() (if you hit
   the right two race windows) - I've tested this in a kernel build with
   some extra mdelay() calls. See the commit message for a description
   of the race scenario.
   On older kernels (before 6.5), I think the same bug can even
   theoretically lead to accessing transhuge page contents as a page table
   if you hit the right 5 narrow race windows (I haven't tested this case).
2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for
   detecting PMDs that don't point to page tables.
   On older kernels (before 6.5), you'd just have to win a single fairly
   wide race to hit this.
   I've tested this on 6.1 stable by racing migration (with a mdelay()
   patched into try_to_migrate()) against UFFDIO_ZEROPAGE - on my x86
   VM, that causes a kernel oops in ptlock_ptr().
3. On newer kernels (&gt;=6.5), for shmem mappings, khugepaged is allowed
   to yank page tables out from under us (though I haven't tested that),
   so I think the BUG_ON() checks in mfill_atomic() are just wrong.
I decided to write two separate fixes for these (one fix for bugs 1+2, one
fix for bug 3), so that the first fix can be backported to kernels
affected by bugs 1+2.
This patch (of 2):
This fixes two issues.
I discovered that the following race can occur:
  mfill_atomic                other thread
  ============                ============
                              &lt;zap PMD&gt;
  pmdp_get_lockless() [reads none pmd]
  &lt;bail if trans_huge&gt;
  &lt;if none:&gt;
                              &lt;pagefault creates transhuge zeropage&gt;
    __pte_alloc [no-op]
                              &lt;zap PMD&gt;
  &lt;bail if pmd_trans_huge(*dst_pmd)&gt;
  BUG_ON(pmd_none(*dst_pmd))
I have experimentally verified this in a kernel with extra mdelay() calls;
the BUG_ON(pmd_none(*dst_pmd)) triggers.
On kernels newer than commit 0d940a9b270b (&quot;mm/pgtable: allow
pte_offset_map[_lock]() to fail&quot;), this can't lead to anything worse than
a BUG_ON(), since the page table access helpers are actually designed to
deal with page tables concurrently disappearing; but on older kernels
(&lt;=6.4), I think we could probably theoretically race past the two
BUG_ON() checks and end up treating a hugepage as a page table.
The second issue is that, as Qi Zheng pointed out, there are other types
of huge PMDs that pmd_trans_huge() can't catch: devmap PMDs and swap PMDs
(in particular, migration PMDs).
On &lt;=6.4, this is worse than the first issue: If mfill_atomic() runs on a
PMD that contains a migration entry (which just requires winning a single,
fairly wide race), it will pass the PMD to pte_offset_map_lock(), which
assumes that the PMD points to a page table.
Breakage follows: First, the kernel tries to take the PTE lock (which will
crash or maybe worse if there is no &quot;struct page&quot; for the address bits in
the migration entry PMD - I think at least on X86 there usually is no
corresponding &quot;struct page&quot; thanks to the PTE inversion mitigation, amd64
looks different).
If that didn't crash, the kernel would next try to write a PTE into what
it wrongly thinks is a page table.
As part of fixing these issues, get rid of the check for pmd_trans_huge()
before __pte_alloc() - that's redundant, we're going to have to check for
that after the __pte_alloc() anyway.
Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.
CVE-2024-46751:In the Linux kernel, the following vulnerability has been resolved:
btrfs: don't BUG_ON() when 0 reference count at btrfs_lookup_extent_info()
Instead of doing a BUG_ON() handle the error by returning -EUCLEAN,
aborting the transaction and logging an error message.
CVE-2024-46752:In the Linux kernel, the following vulnerability has been resolved:
btrfs: replace BUG_ON() with error handling at update_ref_for_cow()
Instead of a BUG_ON() just return an error, log an error message and
abort the transaction in case we find an extent buffer belonging to the
relocation tree that doesn't have the full backref flag set. This is
unexpected and should never happen (save for bugs or a potential bad
memory).
CVE-2024-46733:In the Linux kernel, the following vulnerability has been resolved:
btrfs: fix qgroup reserve leaks in cow_file_range
In the buffered write path, the dirty page owns the qgroup reserve until
it creates an ordered_extent.
Therefore, any errors that occur before the ordered_extent is created
must free that reservation, or else the space is leaked. The fstest
generic/475 exercises various IO error paths, and is able to trigger
errors in cow_file_range where we fail to get to allocating the ordered
extent. Note that because we *do* clear delalloc, we are likely to
remove the inode from the delalloc list, so the inodes/pages to not have
invalidate/launder called on them in the commit abort path.
This results in failures at the unmount stage of the test that look like:
  BTRFS: error (device dm-8 state EA) in cleanup_transaction:2018: errno=-5 IO failure
  BTRFS: error (device dm-8 state EA) in btrfs_replace_file_extents:2416: errno=-5 IO failure
  BTRFS warning (device dm-8 state EA): qgroup 0/5 has unreleased space, type 0 rsv 28672
  ------------[ cut here ]------------
  WARNING: CPU: 3 PID: 22588 at fs/btrfs/disk-io.c:4333 close_ctree+0x222/0x4d0 [btrfs]
  Modules linked in: btrfs blake2b_generic libcrc32c xor zstd_compress raid6_pq
  CPU: 3 PID: 22588 Comm: umount Kdump: loaded Tainted: G W          6.10.0-rc7-gab56fde445b8 #21
  Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Arch Linux 1.16.3-1-1 04/01/2014
  RIP: 0010:close_ctree+0x222/0x4d0 [btrfs]
  RSP: 0018:ffffb4465283be00 EFLAGS: 00010202
  RAX: 0000000000000001 RBX: ffffa1a1818e1000 RCX: 0000000000000001
  RDX: 0000000000000000 RSI: ffffb4465283bbe0 RDI: ffffa1a19374fcb8
  RBP: ffffa1a1818e13c0 R08: 0000000100028b16 R09: 0000000000000000
  R10: 0000000000000003 R11: 0000000000000003 R12: ffffa1a18ad7972c
  R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000
  FS:  00007f9168312b80(0000) GS:ffffa1a4afcc0000(0000) knlGS:0000000000000000
  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
  CR2: 00007f91683c9140 CR3: 000000010acaa000 CR4: 00000000000006f0
  Call Trace:
   &lt;TASK&gt;
   ? close_ctree+0x222/0x4d0 [btrfs]
   ? __warn.cold+0x8e/0xea
   ? close_ctree+0x222/0x4d0 [btrfs]
   ? report_bug+0xff/0x140
   ? handle_bug+0x3b/0x70
   ? exc_invalid_op+0x17/0x70
   ? asm_exc_invalid_op+0x1a/0x20
   ? close_ctree+0x222/0x4d0 [btrfs]
   generic_shutdown_super+0x70/0x160
   kill_anon_super+0x11/0x40
   btrfs_kill_super+0x11/0x20 [btrfs]
   deactivate_locked_super+0x2e/0xa0
   cleanup_mnt+0xb5/0x150
   task_work_run+0x57/0x80
   syscall_exit_to_user_mode+0x121/0x130
   do_syscall_64+0xab/0x1a0
   entry_SYSCALL_64_after_hwframe+0x77/0x7f
  RIP: 0033:0x7f916847a887
  ---[ end trace 0000000000000000 ]---
  BTRFS error (device dm-8 state EA): qgroup reserved space leaked
Cases 2 and 3 in the out_reserve path both pertain to this type of leak
and must free the reserved qgroup data. Because it is already an error
path, I opted not to handle the possible errors in
btrfs_free_qgroup_data.
CVE-2024-46744:In the Linux kernel, the following vulnerability has been resolved:
Squashfs: sanity check symbolic link size
Syzkiller reports a &quot;KMSAN: uninit-value in pick_link&quot; bug.
This is caused by an uninitialised page, which is ultimately caused
by a corrupted symbolic link size read from disk.
The reason why the corrupted symlink size causes an uninitialised
page is due to the following sequence of events:
1. squashfs_read_inode() is called to read the symbolic
   link from disk.  This assigns the corrupted value
   3875536935 to inode-&gt;i_size.
2. Later squashfs_symlink_read_folio() is called, which assigns
   this corrupted value to the length variable, which being a
   signed int, overflows producing a negative number.
3. The following loop that fills in the page contents checks that
   the copied bytes is less than length, which being negative means
   the loop is skipped, producing an uninitialised page.
This patch adds a sanity check which checks that the symbolic
link size is not larger than expected.
--
V2: fix spelling mistake.
CVE-2022-48721:In the Linux kernel, the following vulnerability has been resolved:
net/smc: Forward wakeup to smc socket waitqueue after fallback
When we replace TCP with SMC and a fallback occurs, there may be
some socket waitqueue entries remaining in smc socket-&gt;wq, such
as eppoll_entries inserted by userspace applications.
After the fallback, data flows over TCP/IP and only clcsocket-&gt;wq
will be woken up. Applications can't be notified by the entries
which were inserted in smc socket-&gt;wq before fallback. So we need
a mechanism to wake up smc socket-&gt;wq at the same time if some
entries remaining in it.
The current workaround is to transfer the entries from smc socket-&gt;wq
to clcsock-&gt;wq during the fallback. But this may cause a crash
like this:
 general protection fault, probably for non-canonical address 0xdead000000000100: 0000 [#1] PREEMPT SMP PTI
 CPU: 3 PID: 0 Comm: swapper/3 Kdump: loaded Tainted: G E     5.16.0+ #107
 RIP: 0010:__wake_up_common+0x65/0x170
 Call Trace:
  &lt;IRQ&gt;
  __wake_up_common_lock+0x7a/0xc0
  sock_def_readable+0x3c/0x70
  tcp_data_queue+0x4a7/0xc40
  tcp_rcv_established+0x32f/0x660
  ? sk_filter_trim_cap+0xcb/0x2e0
  tcp_v4_do_rcv+0x10b/0x260
  tcp_v4_rcv+0xd2a/0xde0
  ip_protocol_deliver_rcu+0x3b/0x1d0
  ip_local_deliver_finish+0x54/0x60
  ip_local_deliver+0x6a/0x110
  ? tcp_v4_early_demux+0xa2/0x140
  ? tcp_v4_early_demux+0x10d/0x140
  ip_sublist_rcv_finish+0x49/0x60
  ip_sublist_rcv+0x19d/0x230
  ip_list_rcv+0x13e/0x170
  __netif_receive_skb_list_core+0x1c2/0x240
  netif_receive_skb_list_internal+0x1e6/0x320
  napi_complete_done+0x11d/0x190
  mlx5e_napi_poll+0x163/0x6b0 [mlx5_core]
  __napi_poll+0x3c/0x1b0
  net_rx_action+0x27c/0x300
  __do_softirq+0x114/0x2d2
  irq_exit_rcu+0xb4/0xe0
  common_interrupt+0xba/0xe0
  &lt;/IRQ&gt;
  &lt;TASK&gt;
The crash is caused by privately transferring waitqueue entries from
smc socket-&gt;wq to clcsock-&gt;wq. The owners of these entries, such as
epoll, have no idea that the entries have been transferred to a
different socket wait queue and still use original waitqueue spinlock
(smc socket-&gt;wq.wait.lock) to make the entries operation exclusive,
but it doesn't work. The operations to the entries, such as removing
from the waitqueue (now is clcsock-&gt;wq after fallback), may cause a
crash when clcsock waitqueue is being iterated over at the moment.
This patch tries to fix this by no longer transferring wait queue
entries privately, but introducing own implementations of clcsock's
callback functions in fallback situation. The callback functions will
forward the wakeup to smc socket-&gt;wq if clcsock-&gt;wq is actually woken
up and smc socket-&gt;wq has remaining entries.
CVE-2024-37021:In the Linux kernel, the following vulnerability has been resolved:
fpga: manager: add owner module and take its refcount
The current implementation of the fpga manager assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the manager if
the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_manager
struct and use it to take the module's refcount. Modify the functions for
registering the manager to take an additional owner module parameter and
rename them to avoid conflicts. Use the old function names for helper
macros that automatically set the module that registers the manager as the
owner. This ensures compatibility with existing low-level control modules
and reduces the chances of registering a manager without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga manager.
Other changes: opportunistically move put_device() from __fpga_mgr_get() to
fpga_mgr_get() and of_fpga_mgr_get() to improve code clarity since the
manager device is taken in these functions.
CVE-2021-47622:In the Linux kernel, the following vulnerability has been resolved:
scsi: ufs: Fix a deadlock in the error handler
The following deadlock has been observed on a test setup:
 - All tags allocated
 - The SCSI error handler calls ufshcd_eh_host_reset_handler()
 - ufshcd_eh_host_reset_handler() queues work that calls
   ufshcd_err_handler()
 - ufshcd_err_handler() locks up as follows:
Workqueue: ufs_eh_wq_0 ufshcd_err_handler.cfi_jt
Call trace:
 __switch_to+0x298/0x5d8
 __schedule+0x6cc/0xa94
 schedule+0x12c/0x298
 blk_mq_get_tag+0x210/0x480
 __blk_mq_alloc_request+0x1c8/0x284
 blk_get_request+0x74/0x134
 ufshcd_exec_dev_cmd+0x68/0x640
 ufshcd_verify_dev_init+0x68/0x35c
 ufshcd_probe_hba+0x12c/0x1cb8
 ufshcd_host_reset_and_restore+0x88/0x254
 ufshcd_reset_and_restore+0xd0/0x354
 ufshcd_err_handler+0x408/0xc58
 process_one_work+0x24c/0x66c
 worker_thread+0x3e8/0xa4c
 kthread+0x150/0x1b4
 ret_from_fork+0x10/0x30
Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reserved
request.
CVE-2024-36479:In the Linux kernel, the following vulnerability has been resolved:
fpga: bridge: add owner module and take its refcount
The current implementation of the fpga bridge assumes that the low-level
module registers a driver for the parent device and uses its owner pointer
to take the module's refcount. This approach is problematic since it can
lead to a null pointer dereference while attempting to get the bridge if
the parent device does not have a driver.
To address this problem, add a module owner pointer to the fpga_bridge
struct and use it to take the module's refcount. Modify the function for
registering a bridge to take an additional owner module parameter and
rename it to avoid conflicts. Use the old function name for a helper macro
that automatically sets the module that registers the bridge as the owner.
This ensures compatibility with existing low-level control modules and
reduces the chances of registering a bridge without setting the owner.
Also, update the documentation to keep it consistent with the new interface
for registering an fpga bridge.
Other changes: opportunistically move put_device() from __fpga_bridge_get()
to fpga_bridge_get() and of_fpga_bridge_get() to improve code clarity since
the bridge device is taken in these functions.
CVE-2024-40976:In the Linux kernel, the following vulnerability has been resolved:
drm/lima: mask irqs in timeout path before hard reset
There is a race condition in which a rendering job might take just long
enough to trigger the drm sched job timeout handler but also still
complete before the hard reset is done by the timeout handler.
This runs into race conditions not expected by the timeout handler.
In some very specific cases it currently may result in a refcount
imbalance on lima_pm_idle, with a stack dump such as:
[10136.669170] WARNING: CPU: 0 PID: 0 at drivers/gpu/drm/lima/lima_devfreq.c:205 lima_devfreq_record_idle+0xa0/0xb0
...
[10136.669459] pc : lima_devfreq_record_idle+0xa0/0xb0
...
[10136.669628] Call trace:
[10136.669634]  lima_devfreq_record_idle+0xa0/0xb0
[10136.669646]  lima_sched_pipe_task_done+0x5c/0xb0
[10136.669656]  lima_gp_irq_handler+0xa8/0x120
[10136.669666]  __handle_irq_event_percpu+0x48/0x160
[10136.669679]  handle_irq_event+0x4c/0xc0
We can prevent that race condition entirely by masking the irqs at the
beginning of the timeout handler, at which point we give up on waiting
for that job entirely.
The irqs will be enabled again at the next hard reset which is already
done as a recovery by the timeout handler.
CVE-2024-42105:In the Linux kernel, the following vulnerability has been resolved:
nilfs2: fix inode number range checks
Patch series &quot;nilfs2: fix potential issues related to reserved inodes&quot;.
This series fixes one use-after-free issue reported by syzbot, caused by
nilfs2's internal inode being exposed in the namespace on a corrupted
filesystem, and a couple of flaws that cause problems if the starting
number of non-reserved inodes written in the on-disk super block is
intentionally (or corruptly) changed from its default value.  
This patch (of 3):
In the current implementation of nilfs2, &quot;nilfs-&gt;ns_first_ino&quot;, which
gives the first non-reserved inode number, is read from the superblock,
but its lower limit is not checked.
As a result, if a number that overlaps with the inode number range of
reserved inodes such as the root directory or metadata files is set in the
super block parameter, the inode number test macros (NILFS_MDT_INODE and
NILFS_VALID_INODE) will not function properly.
In addition, these test macros use left bit-shift calculations using with
the inode number as the shift count via the BIT macro, but the result of a
shift calculation that exceeds the bit width of an integer is undefined in
the C specification, so if &quot;ns_first_ino&quot; is set to a large value other
than the default value NILFS_USER_INO (=11), the macros may potentially
malfunction depending on the environment.
Fix these issues by checking the lower bound of &quot;nilfs-&gt;ns_first_ino&quot; and
by preventing bit shifts equal to or greater than the NILFS_USER_INO
constant in the inode number test macros.
Also, change the type of &quot;ns_first_ino&quot; from signed integer to unsigned
integer to avoid the need for type casting in comparisons such as the
lower bound check introduced this time.
CVE-2024-42148:In the Linux kernel, the following vulnerability has been resolved:
bnx2x: Fix multiple UBSAN array-index-out-of-bounds
Fix UBSAN warnings that occur when using a system with 32 physical
cpu cores or more, or when the user defines a number of Ethernet
queues greater than or equal to FP_SB_MAX_E1x using the num_queues
module parameter.
Currently there is a read/write out of bounds that occurs on the array
&quot;struct stats_query_entry query&quot; present inside the &quot;bnx2x_fw_stats_req&quot;
struct in &quot;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h&quot;.
Looking at the definition of the &quot;struct stats_query_entry query&quot; array:
struct stats_query_entry query[FP_SB_MAX_E1x+
         BNX2X_FIRST_QUEUE_QUERY_IDX];
FP_SB_MAX_E1x is defined as the maximum number of fast path interrupts and
has a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3
meaning the array has a total size of 19.
Since accesses to &quot;struct stats_query_entry query&quot; are offset-ted by
BNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernet
queues should not exceed FP_SB_MAX_E1x (16). However one of these queues
is reserved for FCOE and thus the number of Ethernet queues should be set
to [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) if
it is not.
This is also described in a comment in the source code in
drivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definition
of FP_SB_MAX_E1x. Below is the part of this explanation that it important
for this patch
/*
  * The total number of L2 queues, MSIX vectors and HW contexts (CIDs) is
  * control by the number of fast-path status blocks supported by the
  * device (HW/FW). Each fast-path status block (FP-SB) aka non-default
  * status block represents an independent interrupts context that can
  * serve a regular L2 networking queue. However special L2 queues such
  * as the FCoE queue do not require a FP-SB and other components like
  * the CNIC may consume FP-SB reducing the number of possible L2 queues
  *
  * If the maximum number of FP-SB available is X then:
  * a. If CNIC is supported it consumes 1 FP-SB thus the max number of
  *    regular L2 queues is Y=X-1
  * b. In MF mode the actual number of L2 queues is Y= (X-1/MF_factor)
  * c. If the FCoE L2 queue is supported the actual number of L2 queues
  *    is Y+1
  * d. The number of irqs (MSIX vectors) is either Y+1 (one extra for
  *    slow-path interrupts) or Y+2 if CNIC is supported (one additional
  *    FP interrupt context for the CNIC).
  * e. The number of HW context (CID count) is always X or X+1 if FCoE
  *    L2 queue is supported. The cid for the FCoE L2 queue is always X.
  */
However this driver also supports NICs that use the E2 controller which can
handle more queues due to having more FP-SB represented by FP_SB_MAX_E2.
Looking at the commits when the E2 support was added, it was originally
using the E1x parameters: commit f2e0899f0f27 (&quot;bnx2x: Add 57712 support&quot;).
Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driver
was later updated to take full advantage of the E2 instead of having it be
limited to the capabilities of the E1x. But as far as we can tell, the
array &quot;stats_query_entry query&quot; was still limited to using the FP-SB
available to the E1x cards as part of an oversignt when the driver was
updated to take full advantage of the E2, and now with the driver being
aware of the greater queue size supported by E2 NICs, it causes the UBSAN
warnings seen in the stack traces below.
This patch increases the size of the &quot;stats_query_entry query&quot; array by
replacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handle
both types of NICs.
Stack traces:
UBSAN: array-index-out-of-bounds in
       drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11
index 20 is out of range for type 'stats_query_entry [19]'
CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic
	     #202405052133
Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 
---truncated---</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="kernel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-headers" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-devel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="kernel-tools-devel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="perf" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-perf" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="bpftool" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.95.0.176.u140.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-headers" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-headers-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-devel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-devel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-tools-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="kernel-tools-devel" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>kernel-tools-devel-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="perf" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>perf-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-perf" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>python3-perf-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="bpftool" release="136.95.0.176.u140.fos23" version="5.10.0">
					<filename>bpftool-5.10.0-136.95.0.176.u140.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2319</id>
		<title>An update for libgsf is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36474" id="CVE-2024-36474" title="CVE-2024-36474" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42415" id="CVE-2024-42415" title="CVE-2024-42415" type="cve"/>
		</references>
		<description>CVE-2024-36474:An integer overflow vulnerability exists in the Compound Document Binary File format parser of the GNOME Project G Structured File Library (libgsf) version v1.14.52. A specially crafted file can result in an integer overflow when processing the directory from the file that allows for an out-of-bounds index to be used when reading and writing to an array. This can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.
CVE-2024-42415:An integer overflow vulnerability exists in the Compound Document Binary File format parser of v1.14.52 of the GNOME Project G Structured File Library (libgsf). A specially crafted file can result in an integer overflow that allows for a heap-based buffer overflow when processing the sector allocation table. This can lead to arbitrary code execution. An attacker can provide a malicious file to trigger this vulnerability.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="libgsf" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-1.14.47-2.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libgsf-devel" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-devel-1.14.47-2.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="libgsf-help" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-help-1.14.47-2.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libgsf" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-1.14.47-2.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libgsf-devel" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-devel-1.14.47-2.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="libgsf-help" release="2.u1.fos23" version="1.14.47">
					<filename>libgsf-help-1.14.47-2.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2320</id>
		<title>An update for libpcap is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7256" id="CVE-2023-7256" title="CVE-2023-7256" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8006" id="CVE-2024-8006" title="CVE-2024-8006" type="cve"/>
		</references>
		<description>CVE-2023-7256:In affected libpcap versions during the setup of a remote packet capture the internal function sock_initaddress() calls getaddrinfo() and possibly freeaddrinfo(), but does not clearly indicate to the caller function whether freeaddrinfo() still remains to be called after the function returns.  This makes it possible in some scenarios that both the function and its caller call freeaddrinfo() for the same allocated memory block.  A similar problem was reported in Apple libpcap, to which Apple assigned CVE-2023-40400.
CVE-2024-8006:Remote packet capture support is disabled by default in libpcap.  When a user builds libpcap with remote packet capture support enabled, one of the functions that become available is pcap_findalldevs_ex().  One of the function arguments can be a filesystem path, which normally means a directory with input data files.  When the specified path cannot be used as a directory, the function receives NULL from opendir(), but does not check the return value and passes the NULL value to readdir(), which causes a NULL pointer derefence.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="14" name="libpcap" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-1.10.1-4.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="14" name="libpcap-devel" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-devel-1.10.1-4.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="14" name="libpcap-help" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-help-1.10.1-4.u1.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="14" name="libpcap" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-1.10.1-4.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="14" name="libpcap-devel" release="4.u1.fos23" version="1.10.1">
					<filename>libpcap-devel-1.10.1-4.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2321</id>
		<title>An update for nodejs is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46809" id="CVE-2023-46809" title="CVE-2023-46809" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22019" id="CVE-2024-22019" title="CVE-2024-22019" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22025" id="CVE-2024-22025" title="CVE-2024-22025" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27982" id="CVE-2024-27982" title="CVE-2024-27982" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27983" id="CVE-2024-27983" title="CVE-2024-27983" type="cve"/>
		</references>
		<description>CVE-2023-46809:Node.js versions which bundle an unpatched version of OpenSSL or run against a dynamically linked version of OpenSSL which are unpatched are vulnerable to the Marvin Attack - https://people.redhat.com/~hkario/marvin/, if PCKS #1 v1.5 padding is allowed when performing RSA descryption using a private key.
CVE-2024-22019:A vulnerability in Node.js HTTP servers allows an attacker to send a specially crafted HTTP request with chunked encoding, leading to resource exhaustion and denial of service (DoS). The server reads an unbounded number of bytes from a single connection, exploiting the lack of limitations on chunk extension bytes. The issue can cause CPU and network bandwidth exhaustion, bypassing standard safeguards like timeouts and body size limits.
CVE-2024-22025:A vulnerability in Node.js has been identified, allowing for a Denial of Service (DoS) attack through resource exhaustion when using the fetch() function to retrieve content from an untrusted URL.
The vulnerability stems from the fact that the fetch() function in Node.js always decodes Brotli, making it possible for an attacker to cause resource exhaustion when fetching content from an untrusted URL.
An attacker controlling the URL passed into fetch() can exploit this vulnerability to exhaust memory, potentially leading to process termination, depending on the system configuration.
CVE-2024-27982:The team has identified a critical vulnerability in the http server of the most recent version of Node, where malformed headers can lead to HTTP request smuggling. Specifically, if a space is placed before a content-length header, it is not interpreted correctly, enabling attackers to smuggle in a second request within the body of the first.
CVE-2024-27983:An attacker can make the Node.js HTTP/2 server completely unavailable by sending a small amount of HTTP/2 frames packets with a few HTTP/2 frames inside. It is possible to leave some data in nghttp2 memory after reset when headers with HTTP/2 CONTINUATION frame are sent to the server and then a TCP connection is abruptly closed by the client triggering the Http2Session destructor while header frames are still being processed (and stored in memory) causing a race condition.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="nodejs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-10.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-devel" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-10.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-libs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-10.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="nodejs-full-i18n" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-10.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="2" name="v8-devel" release="1.12.22.11.10.u5.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.10.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="npm" release="1.12.22.11.10.u5.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.10.u5.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="1" name="nodejs-docs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-docs-12.22.11-10.u5.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-12.22.11-10.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-devel" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-devel-12.22.11-10.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-libs" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-libs-12.22.11-10.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="nodejs-full-i18n" release="10.u5.fos23" version="12.22.11">
					<filename>nodejs-full-i18n-12.22.11-10.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="2" name="v8-devel" release="1.12.22.11.10.u5.fos23" version="7.8.279.23">
					<filename>v8-devel-7.8.279.23-1.12.22.11.10.u5.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="npm" release="1.12.22.11.10.u5.fos23" version="6.14.16">
					<filename>npm-6.14.16-1.12.22.11.10.u5.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2322</id>
		<title>An update for php is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8925" id="CVE-2024-8925" title="CVE-2024-8925" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8926" id="CVE-2024-8926" title="CVE-2024-8926" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8927" id="CVE-2024-8927" title="CVE-2024-8927" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9026" id="CVE-2024-9026" title="CVE-2024-9026" type="cve"/>
		</references>
		<description>CVE-2024-8925:In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, erroneous parsing of multipart form data contained in an HTTP POST request could lead to legitimate data not being processed. This could lead to malicious attacker able to control part of the submitted data being able to exclude portion of other data, potentially leading to erroneous application behavior.
CVE-2024-8926:In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, when using a certain non-standard configurations of Windows codepages, the fixes for  CVE-2024-4577 https://github.com/advisories/GHSA-vxpp-6299-mxw3  may still be bypassed and the same command injection related to Windows &quot;Best Fit&quot; codepage behavior can be achieved. This may allow a malicious user to pass options to PHP binary being run, and thus reveal the source code of scripts, run arbitrary PHP code on the server, etc.
CVE-2024-8927:In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, HTTP_REDIRECT_STATUS variable is used to check whether or not CGI binary is being run by the HTTP server. However, in certain scenarios, the content of this variable can be controlled by the request submitter via HTTP headers, which can lead to cgi.force_redirect option not being correctly applied. In certain configurations this may lead to arbitrary file inclusion in PHP.
CVE-2024-9026:In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, when using PHP-FPM SAPI and it is configured to catch workers output through catch_workers_output = yes, it may be possible to pollute the final log or remove up to 4 characters from the log messages by manipulating log message content. Additionally, if PHP-FPM is configured to use syslog output, it may be possible to further remove log data using the same vulnerability.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="php" release="6.u4.fos23" version="8.0.30">
					<filename>php-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-cli" release="6.u4.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-dbg" release="6.u4.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-fpm" release="6.u4.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-common" release="6.u4.fos23" version="8.0.30">
					<filename>php-common-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-devel" release="6.u4.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-opcache" release="6.u4.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-ldap" release="6.u4.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-pdo" release="6.u4.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-mysqlnd" release="6.u4.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-pgsql" release="6.u4.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-process" release="6.u4.fos23" version="8.0.30">
					<filename>php-process-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-odbc" release="6.u4.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-soap" release="6.u4.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-snmp" release="6.u4.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-xml" release="6.u4.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-mbstring" release="6.u4.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-gd" release="6.u4.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-bcmath" release="6.u4.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-gmp" release="6.u4.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-dba" release="6.u4.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-tidy" release="6.u4.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-embedded" release="6.u4.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-intl" release="6.u4.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-enchant" release="6.u4.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-sodium" release="6.u4.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-ffi" release="6.u4.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="php-help" release="6.u4.fos23" version="8.0.30">
					<filename>php-help-8.0.30-6.u4.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php" release="6.u4.fos23" version="8.0.30">
					<filename>php-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-cli" release="6.u4.fos23" version="8.0.30">
					<filename>php-cli-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-dbg" release="6.u4.fos23" version="8.0.30">
					<filename>php-dbg-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-fpm" release="6.u4.fos23" version="8.0.30">
					<filename>php-fpm-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-common" release="6.u4.fos23" version="8.0.30">
					<filename>php-common-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-devel" release="6.u4.fos23" version="8.0.30">
					<filename>php-devel-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-opcache" release="6.u4.fos23" version="8.0.30">
					<filename>php-opcache-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-ldap" release="6.u4.fos23" version="8.0.30">
					<filename>php-ldap-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-pdo" release="6.u4.fos23" version="8.0.30">
					<filename>php-pdo-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-mysqlnd" release="6.u4.fos23" version="8.0.30">
					<filename>php-mysqlnd-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-pgsql" release="6.u4.fos23" version="8.0.30">
					<filename>php-pgsql-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-process" release="6.u4.fos23" version="8.0.30">
					<filename>php-process-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-odbc" release="6.u4.fos23" version="8.0.30">
					<filename>php-odbc-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-soap" release="6.u4.fos23" version="8.0.30">
					<filename>php-soap-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-snmp" release="6.u4.fos23" version="8.0.30">
					<filename>php-snmp-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-xml" release="6.u4.fos23" version="8.0.30">
					<filename>php-xml-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-mbstring" release="6.u4.fos23" version="8.0.30">
					<filename>php-mbstring-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-gd" release="6.u4.fos23" version="8.0.30">
					<filename>php-gd-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-bcmath" release="6.u4.fos23" version="8.0.30">
					<filename>php-bcmath-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-gmp" release="6.u4.fos23" version="8.0.30">
					<filename>php-gmp-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-dba" release="6.u4.fos23" version="8.0.30">
					<filename>php-dba-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-tidy" release="6.u4.fos23" version="8.0.30">
					<filename>php-tidy-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-embedded" release="6.u4.fos23" version="8.0.30">
					<filename>php-embedded-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-intl" release="6.u4.fos23" version="8.0.30">
					<filename>php-intl-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-enchant" release="6.u4.fos23" version="8.0.30">
					<filename>php-enchant-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-sodium" release="6.u4.fos23" version="8.0.30">
					<filename>php-sodium-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-ffi" release="6.u4.fos23" version="8.0.30">
					<filename>php-ffi-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="php-help" release="6.u4.fos23" version="8.0.30">
					<filename>php-help-8.0.30-6.u4.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2323</id>
		<title>An update for poppler is now available for FusionOS 23</title>
		<severity>Low</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4141" id="CVE-2024-4141" title="CVE-2024-4141" type="cve"/>
		</references>
		<description>CVE-2024-4141:Out-of-bounds array write in Xpdf 4.05 and earlier, triggered by an invalid character code in a Type 1 font. The root problem was a bounds check that was being optimized away by modern compilers.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="poppler" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-glib-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="poppler-glib-doc" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-doc-0.90.0-9.u6.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-qt5-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-cpp-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="poppler-utils" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-9.u6.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="poppler-help" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-help-0.90.0-9.u6.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-devel-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-glib-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-glib-devel-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-qt5-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-qt5-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-qt5-devel-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-cpp-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-cpp-devel" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-cpp-devel-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="poppler-utils" release="9.u6.fos23" version="0.90.0">
					<filename>poppler-utils-0.90.0-9.u6.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2324</id>
		<title>An update for python-configobj is now available for FusionOS 23</title>
		<severity>Moderate</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26112" id="CVE-2023-26112" title="CVE-2023-26112" type="cve"/>
		</references>
		<description>CVE-2023-26112:All versions of the package configobj are vulnerable to Regular Expression Denial of Service (ReDoS) via the validate function, using (.+?)\((.*)\).
**Note:** This is only exploitable in the case of a developer, putting the offending value in a server side configuration file.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="noarch" epoch="0" name="python3-configobj" release="20.u2.fos23" version="5.0.6">
					<filename>python3-configobj-5.0.6-20.u2.fos23.noarch.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2325</id>
		<title>An update for python3 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6923" id="CVE-2024-6923" title="CVE-2024-6923" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7592" id="CVE-2024-7592" title="CVE-2024-7592" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8088" id="CVE-2024-8088" title="CVE-2024-8088" type="cve"/>
		</references>
		<description>CVE-2024-6923:There is a MEDIUM severity vulnerability affecting CPython.
The 
email module didn’t properly quote newlines for email headers when 
serializing an email message allowing for header injection when an email
 is serialized.
CVE-2024-7592:There is a LOW severity vulnerability affecting CPython, specifically the
'http.cookies' standard library module.
When parsing cookies that contained backslashes for quoted characters in
the cookie value, the parser would use an algorithm with quadratic
complexity, resulting in excess CPU resources being used while parsing the
value.
CVE-2024-8088:There is a HIGH severity vulnerability affecting the CPython &quot;zipfile&quot;
module affecting &quot;zipfile.Path&quot;. Note that the more common API &quot;zipfile.ZipFile&quot; class is unaffected.
When iterating over names of entries in a zip archive (for example, methods
of &quot;zipfile.Path&quot; like &quot;namelist()&quot;, &quot;iterdir()&quot;, etc)
the process can be put into an infinite loop with a maliciously crafted
zip archive. This defect applies when reading only metadata or extracting
the contents of the zip archive. Programs that are not handling
user-controlled zip archives are not affected.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="python3" release="31.u14.fos23" version="3.9.9">
					<filename>python3-3.9.9-31.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unversioned-command" release="31.u14.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-31.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-devel" release="31.u14.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-31.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-debug" release="31.u14.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-31.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="python3-help" release="31.u14.fos23" version="3.9.9">
					<filename>python3-help-3.9.9-31.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3" release="31.u14.fos23" version="3.9.9">
					<filename>python3-3.9.9-31.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unversioned-command" release="31.u14.fos23" version="3.9.9">
					<filename>python3-unversioned-command-3.9.9-31.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-devel" release="31.u14.fos23" version="3.9.9">
					<filename>python3-devel-3.9.9-31.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-debug" release="31.u14.fos23" version="3.9.9">
					<filename>python3-debug-3.9.9-31.u14.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2326</id>
		<title>An update for redis6 is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31228" id="CVE-2024-31228" title="CVE-2024-31228" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31449" id="CVE-2024-31449" title="CVE-2024-31449" type="cve"/>
		</references>
		<description>CVE-2024-31228:Redis is an open source, in-memory database that persists on disk. Authenticated users can trigger a denial-of-service by using specially crafted, long string match patterns on supported commands such as `KEYS`, `SCAN`, `PSUBSCRIBE`, `FUNCTION LIST`, `COMMAND LIST` and ACL definitions. Matching of extremely long patterns may result in unbounded recursion, leading to stack overflow and process crash. This problem has been fixed in Redis versions 6.2.16, 7.2.6, and 7.4.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.
CVE-2024-31449:Redis is an open source, in-memory database that persists on disk. An authenticated user may use a specially crafted Lua script to trigger a stack buffer overflow in the bit library, which may potentially lead to remote code execution. The problem exists in all versions of Redis with Lua scripting. This problem has been fixed in Redis versions 6.2.16, 7.2.6, and 7.4.1. Users are advised to upgrade. There are no known workarounds for this vulnerability.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="redis6" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="redis6-devel" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="redis6-doc" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-doc-6.2.7-3.u8.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="redis6" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-6.2.7-3.u8.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="redis6-devel" release="3.u8.fos23" version="6.2.7">
					<filename>redis6-devel-6.2.7-3.u8.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2327</id>
		<title>An update for ruby is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47220" id="CVE-2024-47220" title="CVE-2024-47220" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39908" id="CVE-2024-39908" title="CVE-2024-39908" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41123" id="CVE-2024-41123" title="CVE-2024-41123" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43398" id="CVE-2024-43398" title="CVE-2024-43398" type="cve"/>
		</references>
		<description>CVE-2024-47220:An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., &quot;GET /admin HTTP/1.1\r\n&quot; inside of a &quot;POST /user HTTP/1.1\r\n&quot; request. NOTE: the supplier's position is &quot;Webrick should not be used in production.&quot;
CVE-2024-39908:REXML is an XML toolkit for Ruby. The REXML gem before 3.3.1 has some DoS vulnerabilities when it parses an XML that has many specific characters such as `&lt;`, `0` and `%&gt;`. If you need to parse untrusted XMLs, you many be impacted to these vulnerabilities. The REXML gem 3.3.2 or later include the patches to fix these vulnerabilities. Users are advised to upgrade. Users unable to upgrade should avoid parsing untrusted XML strings.
CVE-2024-41123:REXML is an XML toolkit for Ruby. The REXML gem before 3.3.2 has some DoS vulnerabilities when it parses an XML that has many specific characters such as whitespace character, `&gt;]` and `]&gt;`. The REXML gem 3.3.3 or later include the patches to fix these vulnerabilities.
CVE-2024-43398:REXML is an XML toolkit for Ruby. The REXML gem before 3.3.6 has a DoS vulnerability when it parses an XML that has many deep elements that have same local name attributes. If you need to parse untrusted XMLs with tree parser API like REXML::Document.new, you may be impacted to this vulnerability. If you use other parser APIs such as stream parser API and SAX2 parser API, this vulnerability is not affected. The REXML gem 3.3.6 or later include the patch to fix the vulnerability.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="ruby" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-3.0.3-140.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="ruby-devel" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-140.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygems" release="140.u14.fos23" version="3.2.32">
					<filename>rubygems-3.2.32-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygems-devel" release="140.u14.fos23" version="3.2.32">
					<filename>rubygems-devel-3.2.32-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rake" release="140.u14.fos23" version="13.0.3">
					<filename>rubygem-rake-13.0.3-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rbs" release="140.u14.fos23" version="1.4.0">
					<filename>rubygem-rbs-1.4.0-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="ruby-irb" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-irb-3.0.3-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rdoc" release="140.u14.fos23" version="6.3.3">
					<filename>rubygem-rdoc-6.3.3-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="ruby-help" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-help-3.0.3-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-bigdecimal" release="140.u14.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-140.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-did_you_mean" release="140.u14.fos23" version="1.5.0">
					<filename>rubygem-did_you_mean-1.5.0-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-io-console" release="140.u14.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-140.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-json" release="140.u14.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-140.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-minitest" release="140.u14.fos23" version="5.14.2">
					<filename>rubygem-minitest-5.14.2-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-openssl" release="140.u14.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-140.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="rubygem-psych" release="140.u14.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-140.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-test-unit" release="140.u14.fos23" version="3.3.7">
					<filename>rubygem-test-unit-3.3.7-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rexml" release="140.u14.fos23" version="3.2.5">
					<filename>rubygem-rexml-3.2.5-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-rss" release="140.u14.fos23" version="0.2.9">
					<filename>rubygem-rss-0.2.9-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-typeprof" release="140.u14.fos23" version="0.15.2">
					<filename>rubygem-typeprof-0.15.2-140.u14.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ruby" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-3.0.3-140.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="ruby-devel" release="140.u14.fos23" version="3.0.3">
					<filename>ruby-devel-3.0.3-140.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-bigdecimal" release="140.u14.fos23" version="3.0.0">
					<filename>rubygem-bigdecimal-3.0.0-140.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-io-console" release="140.u14.fos23" version="0.5.7">
					<filename>rubygem-io-console-0.5.7-140.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-json" release="140.u14.fos23" version="2.5.1">
					<filename>rubygem-json-2.5.1-140.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-openssl" release="140.u14.fos23" version="2.2.1">
					<filename>rubygem-openssl-2.2.1-140.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="rubygem-psych" release="140.u14.fos23" version="3.3.2">
					<filename>rubygem-psych-3.3.2-140.u14.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2328</id>
		<title>An update for rubygem-webrick is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47220" id="CVE-2024-47220" title="CVE-2024-47220" type="cve"/>
		</references>
		<description>CVE-2024-47220:An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., &quot;GET /admin HTTP/1.1\r\n&quot; inside of a &quot;POST /user HTTP/1.1\r\n&quot; request. NOTE: the supplier's position is &quot;Webrick should not be used in production.&quot;</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="noarch" epoch="0" name="rubygem-webrick" release="2.u1.fos23" version="1.7.0">
					<filename>rubygem-webrick-1.7.0-2.u1.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="rubygem-webrick-help" release="2.u1.fos23" version="1.7.0">
					<filename>rubygem-webrick-help-1.7.0-2.u1.fos23.noarch.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2329</id>
		<title>An update for scsi-target-utils is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45751" id="CVE-2024-45751" title="CVE-2024-45751" type="cve"/>
		</references>
		<description>CVE-2024-45751:tgt (aka Linux target framework) before 1.0.93 attempts to achieve entropy by calling rand without srand. The PRNG seed is always 1, and thus the sequence of challenges is always identical.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="scsi-target-utils" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-1.0.79-6.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="scsi-target-utils-rbd" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-rbd-1.0.79-6.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="scsi-target-utils-gluster" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-gluster-1.0.79-6.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="scsi-target-utils-help" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-help-1.0.79-6.u2.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="scsi-target-utils" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-1.0.79-6.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="scsi-target-utils-rbd" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-rbd-1.0.79-6.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="scsi-target-utils-gluster" release="6.u2.fos23" version="1.0.79">
					<filename>scsi-target-utils-gluster-1.0.79-6.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2330</id>
		<title>An update for squid is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25111" id="CVE-2024-25111" title="CVE-2024-25111" type="cve"/>
		</references>
		<description>CVE-2024-25111:Squid is a web proxy cache. Starting in version 3.5.27 and prior to version 6.8, Squid may be vulnerable to a Denial of Service attack against HTTP Chunked decoder due to an uncontrolled recursion bug. This problem allows a remote attacker to cause Denial of Service when sending a crafted, chunked, encoded HTTP Message. This bug is fixed in Squid version 6.8. In addition, patches addressing this problem for the stable releases can be found in Squid's patch archives. There is no workaround for this issue.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="7" name="squid" release="26.u7.fos23" version="4.9">
					<filename>squid-4.9-26.u7.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="squid" release="26.u7.fos23" version="4.9">
					<filename>squid-4.9-26.u7.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2331</id>
		<title>An update for texlive-base is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32700" id="CVE-2023-32700" title="CVE-2023-32700" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46048" id="CVE-2023-46048" title="CVE-2023-46048" 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.
CVE-2023-46048:Tex Live 944e257 has a NULL pointer dereference in texk/web2c/pdftexdir/writet1.c. NOTE: this is disputed because it should be categorized as a usability problem.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="7" name="texlive-base" release="38.u3.fos23" version="20180414">
					<filename>texlive-base-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-a2ping" release="38.u3.fos23" version="20180414">
					<filename>texlive-a2ping-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-accfonts" release="38.u3.fos23" version="20180414">
					<filename>texlive-accfonts-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-adhocfilelist" release="38.u3.fos23" version="20180414">
					<filename>texlive-adhocfilelist-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-afm2pl" release="38.u3.fos23" version="20180414">
					<filename>texlive-afm2pl-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-aleph" release="38.u3.fos23" version="20180414">
					<filename>texlive-aleph-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-amstex" release="38.u3.fos23" version="20180414">
					<filename>texlive-amstex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-arara" release="38.u3.fos23" version="20180414">
					<filename>texlive-arara-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-authorindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-authorindex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-autosp" release="38.u3.fos23" version="20180414">
					<filename>texlive-autosp-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-axodraw2" release="38.u3.fos23" version="20180414">
					<filename>texlive-axodraw2-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bib2gls" release="38.u3.fos23" version="20180414">
					<filename>texlive-bib2gls-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bibexport" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibexport-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtex" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtexu" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtexu-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-bibtex8" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtex8-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-bundledoc" release="38.u3.fos23" version="20180414">
					<filename>texlive-bundledoc-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cachepic" release="38.u3.fos23" version="20180414">
					<filename>texlive-cachepic-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-checkcites" release="38.u3.fos23" version="20180414">
					<filename>texlive-checkcites-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-checklistings" release="38.u3.fos23" version="20180414">
					<filename>texlive-checklistings-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-chktex" release="38.u3.fos23" version="20180414">
					<filename>texlive-chktex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-cjkutils" release="38.u3.fos23" version="20180414">
					<filename>texlive-cjkutils-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-context" release="38.u3.fos23" version="20180414">
					<filename>texlive-context-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-convbkmk" release="38.u3.fos23" version="20180414">
					<filename>texlive-convbkmk-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-crossrefware" release="38.u3.fos23" version="20180414">
					<filename>texlive-crossrefware-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cslatex" release="38.u3.fos23" version="20180414">
					<filename>texlive-cslatex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-csplain" release="38.u3.fos23" version="20180414">
					<filename>texlive-csplain-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ctan-o-mat" release="38.u3.fos23" version="20180414">
					<filename>texlive-ctan-o-mat-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ctanify" release="38.u3.fos23" version="20180414">
					<filename>texlive-ctanify-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ctie" release="38.u3.fos23" version="20180414">
					<filename>texlive-ctie-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-cweb" release="38.u3.fos23" version="20180414">
					<filename>texlive-cweb-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-cyrillic" release="38.u3.fos23" version="20180414">
					<filename>texlive-cyrillic-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-de-macro" release="38.u3.fos23" version="20180414">
					<filename>texlive-de-macro-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-detex" release="38.u3.fos23" version="20180414">
					<filename>texlive-detex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-diadia" release="38.u3.fos23" version="20180414">
					<filename>texlive-diadia-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dosepsbin" release="38.u3.fos23" version="20180414">
					<filename>texlive-dosepsbin-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dtl" release="38.u3.fos23" version="20180414">
					<filename>texlive-dtl-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dtxgen" release="38.u3.fos23" version="20180414">
					<filename>texlive-dtxgen-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvi2tty" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvi2tty-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dviasm" release="38.u3.fos23" version="20180414">
					<filename>texlive-dviasm-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvicopy" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvicopy-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvidvi" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvidvi-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-dviinfox" release="38.u3.fos23" version="20180414">
					<filename>texlive-dviinfox-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dviljk" release="38.u3.fos23" version="20180414">
					<filename>texlive-dviljk-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipdfmx" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipdfmx-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipng" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipng-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvipos" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipos-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvips" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvips-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-dvisvgm" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvisvgm-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ebong" release="38.u3.fos23" version="20180414">
					<filename>texlive-ebong-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-eplain" release="38.u3.fos23" version="20180414">
					<filename>texlive-eplain-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-epspdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-epspdf-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-epstopdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-epstopdf-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fig4latex" release="38.u3.fos23" version="20180414">
					<filename>texlive-fig4latex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-findhyph" release="38.u3.fos23" version="20180414">
					<filename>texlive-findhyph-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fontinst" release="38.u3.fos23" version="20180414">
					<filename>texlive-fontinst-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fontools" release="38.u3.fos23" version="20180414">
					<filename>texlive-fontools-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-fontware" release="38.u3.fos23" version="20180414">
					<filename>texlive-fontware-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-fragmaster" release="38.u3.fos23" version="20180414">
					<filename>texlive-fragmaster-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-getmap" release="38.u3.fos23" version="20180414">
					<filename>texlive-getmap-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-glossaries" release="38.u3.fos23" version="20180414">
					<filename>texlive-glossaries-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-glyphlist" release="38.u3.fos23" version="20180414">
					<filename>texlive-glyphlist-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-gregoriotex" release="38.u3.fos23" version="20180414">
					<filename>texlive-gregoriotex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-gsftopk" release="38.u3.fos23" version="20180414">
					<filename>texlive-gsftopk-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-installfont" release="38.u3.fos23" version="20180414">
					<filename>texlive-installfont-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-jadetex" release="38.u3.fos23" version="20180414">
					<filename>texlive-jadetex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-jfmutil" release="38.u3.fos23" version="20180414">
					<filename>texlive-jfmutil-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-kotex-utils" release="38.u3.fos23" version="20180414">
					<filename>texlive-kotex-utils-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-kpathsea" release="38.u3.fos23" version="20180414">
					<filename>texlive-kpathsea-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-l3build" release="38.u3.fos23" version="20180414">
					<filename>texlive-l3build-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lacheck" release="38.u3.fos23" version="20180414">
					<filename>texlive-lacheck-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex-git-log" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex-git-log-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex-papersize" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex-papersize-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex2man" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex2man-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latex2nemeth" release="38.u3.fos23" version="20180414">
					<filename>texlive-latex2nemeth-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexdiff" release="38.u3.fos23" version="20180414">
					<filename>texlive-latexdiff-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexfileversion" release="38.u3.fos23" version="20180414">
					<filename>texlive-latexfileversion-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-latexpand" release="38.u3.fos23" version="20180414">
					<filename>texlive-latexpand-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lcdftypetools" release="38.u3.fos23" version="20180414">
					<filename>texlive-lcdftypetools-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lib" release="38.u3.fos23" version="20180414">
					<filename>texlive-lib-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-lib-devel" release="38.u3.fos23" version="20180414">
					<filename>texlive-lib-devel-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lilyglyphs" release="38.u3.fos23" version="20180414">
					<filename>texlive-lilyglyphs-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-listbib" release="38.u3.fos23" version="20180414">
					<filename>texlive-listbib-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-listings-ext" release="38.u3.fos23" version="20180414">
					<filename>texlive-listings-ext-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lollipop" release="38.u3.fos23" version="20180414">
					<filename>texlive-lollipop-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ltxfileinfo" release="38.u3.fos23" version="20180414">
					<filename>texlive-ltxfileinfo-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ltximg" release="38.u3.fos23" version="20180414">
					<filename>texlive-ltximg-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lua2dox" release="38.u3.fos23" version="20180414">
					<filename>texlive-lua2dox-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-luaotfload" release="38.u3.fos23" version="20180414">
					<filename>texlive-luaotfload-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-luatex" release="38.u3.fos23" version="20180414">
					<filename>texlive-luatex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lwarp" release="38.u3.fos23" version="20180414">
					<filename>texlive-lwarp-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-lyluatex" release="38.u3.fos23" version="svn47584">
					<filename>texlive-lyluatex-svn47584-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-make4ht" release="38.u3.fos23" version="20180414">
					<filename>texlive-make4ht-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-makedtx" release="38.u3.fos23" version="20180414">
					<filename>texlive-makedtx-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-makeindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-makeindex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-match_parens" release="38.u3.fos23" version="20180414">
					<filename>texlive-match_parens-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mathspic" release="38.u3.fos23" version="20180414">
					<filename>texlive-mathspic-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-metafont" release="38.u3.fos23" version="20180414">
					<filename>texlive-metafont-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-metapost" release="38.u3.fos23" version="20180414">
					<filename>texlive-metapost-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mex" release="38.u3.fos23" version="20180414">
					<filename>texlive-mex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-mflua" release="38.u3.fos23" version="20180414">
					<filename>texlive-mflua-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-mfware" release="38.u3.fos23" version="20180414">
					<filename>texlive-mfware-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mf2pt1" release="38.u3.fos23" version="20180414">
					<filename>texlive-mf2pt1-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkgrkindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-mkgrkindex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkjobtexmf" release="38.u3.fos23" version="20180414">
					<filename>texlive-mkjobtexmf-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mkpic" release="38.u3.fos23" version="20180414">
					<filename>texlive-mkpic-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mltex" release="38.u3.fos23" version="20180414">
					<filename>texlive-mltex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-mptopdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-mptopdf-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-multibibliography" release="38.u3.fos23" version="20180414">
					<filename>texlive-multibibliography-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-musixtex" release="38.u3.fos23" version="20180414">
					<filename>texlive-musixtex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-musixtnt" release="38.u3.fos23" version="20180414">
					<filename>texlive-musixtnt-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-m-tx" release="38.u3.fos23" version="20180414">
					<filename>texlive-m-tx-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-oberdiek" release="38.u3.fos23" version="20180414">
					<filename>texlive-oberdiek-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-omegaware" release="38.u3.fos23" version="20180414">
					<filename>texlive-omegaware-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-patgen" release="38.u3.fos23" version="20180414">
					<filename>texlive-patgen-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pax" release="38.u3.fos23" version="20180414">
					<filename>texlive-pax-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfbook2" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdfbook2-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfcrop" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdfcrop-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfjam" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdfjam-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdflatexpicscale" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdflatexpicscale-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pdftex" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdftex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pdftools" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdftools-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pdfxup" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdfxup-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pedigree-perl" release="38.u3.fos23" version="20180414">
					<filename>texlive-pedigree-perl-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-perltex" release="38.u3.fos23" version="20180414">
					<filename>texlive-perltex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-petri-nets" release="38.u3.fos23" version="20180414">
					<filename>texlive-petri-nets-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pfarrei" release="38.u3.fos23" version="20180414">
					<filename>texlive-pfarrei-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pkfix" release="38.u3.fos23" version="20180414">
					<filename>texlive-pkfix-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pkfix-helper" release="38.u3.fos23" version="20180414">
					<filename>texlive-pkfix-helper-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pmx" release="38.u3.fos23" version="20180414">
					<filename>texlive-pmx-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pmxchords" release="38.u3.fos23" version="20180414">
					<filename>texlive-pmxchords-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-pstools" release="38.u3.fos23" version="20180414">
					<filename>texlive-pstools-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pst2pdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-pst2pdf-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pst-pdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-pst-pdf-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ps2pk" release="38.u3.fos23" version="20180414">
					<filename>texlive-ps2pk-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ptex" release="38.u3.fos23" version="20180414">
					<filename>texlive-ptex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ptex-fontmaps" release="38.u3.fos23" version="20180414">
					<filename>texlive-ptex-fontmaps-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ptex2pdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-ptex2pdf-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-purifyeps" release="38.u3.fos23" version="20180414">
					<filename>texlive-purifyeps-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pygmentex" release="38.u3.fos23" version="20180414">
					<filename>texlive-pygmentex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-pythontex" release="38.u3.fos23" version="20180414">
					<filename>texlive-pythontex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-rubik" release="38.u3.fos23" version="20180414">
					<filename>texlive-rubik-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-seetexk" release="38.u3.fos23" version="20180414">
					<filename>texlive-seetexk-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-splitindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-splitindex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-srcredact" release="38.u3.fos23" version="20180414">
					<filename>texlive-srcredact-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-sty2dtx" release="38.u3.fos23" version="20180414">
					<filename>texlive-sty2dtx-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-svn-multi" release="38.u3.fos23" version="20180414">
					<filename>texlive-svn-multi-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-synctex" release="38.u3.fos23" version="20180414">
					<filename>texlive-synctex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tetex" release="38.u3.fos23" version="20180414">
					<filename>texlive-tetex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tex" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tex4ebook" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex4ebook-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tex4ht" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex4ht-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texconfig" release="38.u3.fos23" version="20180414">
					<filename>texlive-texconfig-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texcount" release="38.u3.fos23" version="20180414">
					<filename>texlive-texcount-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdef" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdef-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdiff" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdiff-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdirflatten" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdirflatten-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdoc" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdoc-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texdoctk" release="38.u3.fos23" version="20180414">
					<filename>texlive-texdoctk-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texfot" release="38.u3.fos23" version="20180414">
					<filename>texlive-texfot-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texliveonfly" release="38.u3.fos23" version="20180414">
					<filename>texlive-texliveonfly-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive-en" release="38.u3.fos23" version="20180414">
					<filename>texlive-texlive-en-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive-scripts" release="38.u3.fos23" version="20180414">
					<filename>texlive-texlive-scripts-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texlive.infra" release="38.u3.fos23" version="20180414">
					<filename>texlive-texlive.infra-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texloganalyser" release="38.u3.fos23" version="20180414">
					<filename>texlive-texloganalyser-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texosquery" release="38.u3.fos23" version="20180414">
					<filename>texlive-texosquery-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-texsis" release="38.u3.fos23" version="20180414">
					<filename>texlive-texsis-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-texware" release="38.u3.fos23" version="20180414">
					<filename>texlive-texware-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-thumbpdf" release="38.u3.fos23" version="20180414">
					<filename>texlive-thumbpdf-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-tie" release="38.u3.fos23" version="20180414">
					<filename>texlive-tie-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-tpic2pdftex" release="38.u3.fos23" version="20180414">
					<filename>texlive-tpic2pdftex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-ttfutils" release="38.u3.fos23" version="20180414">
					<filename>texlive-ttfutils-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-typeoutfileinfo" release="38.u3.fos23" version="20180414">
					<filename>texlive-typeoutfileinfo-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-ulqda" release="38.u3.fos23" version="20180414">
					<filename>texlive-ulqda-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-uptex" release="38.u3.fos23" version="20180414">
					<filename>texlive-uptex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-urlbst" release="38.u3.fos23" version="20180414">
					<filename>texlive-urlbst-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-velthuis" release="38.u3.fos23" version="20180414">
					<filename>texlive-velthuis-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-vlna" release="38.u3.fos23" version="20180414">
					<filename>texlive-vlna-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-vpe" release="38.u3.fos23" version="20180414">
					<filename>texlive-vpe-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-web" release="38.u3.fos23" version="20180414">
					<filename>texlive-web-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-wordcount" release="38.u3.fos23" version="20180414">
					<filename>texlive-wordcount-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-xdvi" release="38.u3.fos23" version="20180414">
					<filename>texlive-xdvi-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="7" name="texlive-xetex" release="38.u3.fos23" version="20180414">
					<filename>texlive-xetex-20180414-38.u3.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-xmltex" release="38.u3.fos23" version="20180414">
					<filename>texlive-xmltex-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="noarch" epoch="7" name="texlive-yplan" release="38.u3.fos23" version="20180414">
					<filename>texlive-yplan-20180414-38.u3.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-base" release="38.u3.fos23" version="20180414">
					<filename>texlive-base-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-afm2pl" release="38.u3.fos23" version="20180414">
					<filename>texlive-afm2pl-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-aleph" release="38.u3.fos23" version="20180414">
					<filename>texlive-aleph-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-autosp" release="38.u3.fos23" version="20180414">
					<filename>texlive-autosp-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-axodraw2" release="38.u3.fos23" version="20180414">
					<filename>texlive-axodraw2-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtex" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtexu" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtexu-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-bibtex8" release="38.u3.fos23" version="20180414">
					<filename>texlive-bibtex8-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-chktex" release="38.u3.fos23" version="20180414">
					<filename>texlive-chktex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-cjkutils" release="38.u3.fos23" version="20180414">
					<filename>texlive-cjkutils-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ctie" release="38.u3.fos23" version="20180414">
					<filename>texlive-ctie-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-cweb" release="38.u3.fos23" version="20180414">
					<filename>texlive-cweb-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-detex" release="38.u3.fos23" version="20180414">
					<filename>texlive-detex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dtl" release="38.u3.fos23" version="20180414">
					<filename>texlive-dtl-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvi2tty" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvi2tty-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvicopy" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvicopy-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvidvi" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvidvi-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dviljk" release="38.u3.fos23" version="20180414">
					<filename>texlive-dviljk-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipdfmx" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipdfmx-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipng" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipng-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvipos" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvipos-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvips" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvips-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-dvisvgm" release="38.u3.fos23" version="20180414">
					<filename>texlive-dvisvgm-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-fontware" release="38.u3.fos23" version="20180414">
					<filename>texlive-fontware-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-gregoriotex" release="38.u3.fos23" version="20180414">
					<filename>texlive-gregoriotex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-gsftopk" release="38.u3.fos23" version="20180414">
					<filename>texlive-gsftopk-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-kpathsea" release="38.u3.fos23" version="20180414">
					<filename>texlive-kpathsea-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lacheck" release="38.u3.fos23" version="20180414">
					<filename>texlive-lacheck-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lcdftypetools" release="38.u3.fos23" version="20180414">
					<filename>texlive-lcdftypetools-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lib" release="38.u3.fos23" version="20180414">
					<filename>texlive-lib-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-lib-devel" release="38.u3.fos23" version="20180414">
					<filename>texlive-lib-devel-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-luatex" release="38.u3.fos23" version="20180414">
					<filename>texlive-luatex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-makeindex" release="38.u3.fos23" version="20180414">
					<filename>texlive-makeindex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-metafont" release="38.u3.fos23" version="20180414">
					<filename>texlive-metafont-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-metapost" release="38.u3.fos23" version="20180414">
					<filename>texlive-metapost-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-mflua" release="38.u3.fos23" version="20180414">
					<filename>texlive-mflua-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-mfware" release="38.u3.fos23" version="20180414">
					<filename>texlive-mfware-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-musixtnt" release="38.u3.fos23" version="20180414">
					<filename>texlive-musixtnt-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-m-tx" release="38.u3.fos23" version="20180414">
					<filename>texlive-m-tx-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-omegaware" release="38.u3.fos23" version="20180414">
					<filename>texlive-omegaware-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-patgen" release="38.u3.fos23" version="20180414">
					<filename>texlive-patgen-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pdftex" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdftex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pdftools" release="38.u3.fos23" version="20180414">
					<filename>texlive-pdftools-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pmx" release="38.u3.fos23" version="20180414">
					<filename>texlive-pmx-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-pstools" release="38.u3.fos23" version="20180414">
					<filename>texlive-pstools-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ps2pk" release="38.u3.fos23" version="20180414">
					<filename>texlive-ps2pk-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ptex" release="38.u3.fos23" version="20180414">
					<filename>texlive-ptex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-seetexk" release="38.u3.fos23" version="20180414">
					<filename>texlive-seetexk-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-synctex" release="38.u3.fos23" version="20180414">
					<filename>texlive-synctex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tex" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tex4ht" release="38.u3.fos23" version="20180414">
					<filename>texlive-tex4ht-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-texware" release="38.u3.fos23" version="20180414">
					<filename>texlive-texware-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-tie" release="38.u3.fos23" version="20180414">
					<filename>texlive-tie-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-ttfutils" release="38.u3.fos23" version="20180414">
					<filename>texlive-ttfutils-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-uptex" release="38.u3.fos23" version="20180414">
					<filename>texlive-uptex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-velthuis" release="38.u3.fos23" version="20180414">
					<filename>texlive-velthuis-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-vlna" release="38.u3.fos23" version="20180414">
					<filename>texlive-vlna-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-web" release="38.u3.fos23" version="20180414">
					<filename>texlive-web-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-xdvi" release="38.u3.fos23" version="20180414">
					<filename>texlive-xdvi-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="7" name="texlive-xetex" release="38.u3.fos23" version="20180414">
					<filename>texlive-xetex-20180414-38.u3.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2332</id>
		<title>An update for uboot-tools is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2347" id="CVE-2022-2347" title="CVE-2022-2347" type="cve"/>
		</references>
		<description>CVE-2022-2347:There exists an unchecked length field in UBoot. The U-Boot DFU implementation does not bound the length field in USB DFU download setup packets, and it does not verify that the transfer direction corresponds to the specified command. Consequently, if a physical attacker crafts a USB DFU download setup packet with a `wLength` greater than 4096 bytes, they can write beyond the heap-allocated request buffer.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="uboot-tools" release="8.u1.fos23" version="2021.10">
					<filename>uboot-tools-2021.10-8.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="uboot-tools-help" release="8.u1.fos23" version="2021.10">
					<filename>uboot-tools-help-2021.10-8.u1.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="uboot-tools" release="8.u1.fos23" version="2021.10">
					<filename>uboot-tools-2021.10-8.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2333</id>
		<title>An update for unbound is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8508" id="CVE-2024-8508" title="CVE-2024-8508" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33655" id="CVE-2024-33655" title="CVE-2024-33655" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43168" id="CVE-2024-43168" title="CVE-2024-43168" type="cve"/>
		</references>
		<description>CVE-2024-8508:NLnet Labs Unbound up to and including version 1.21.0 contains a vulnerability when handling replies with very large RRsets that it needs to perform name compression for. Malicious upstreams responses with very large RRsets can cause Unbound to spend a considerable time applying name compression to downstream replies. This can lead to degraded performance and eventually denial of service in well orchestrated attacks. The vulnerability can be exploited by a malicious actor querying Unbound for the specially crafted contents of a malicious zone with very large RRsets. Before Unbound replies to the query it will try to apply name compression which was an unbounded operation that could lock the CPU until the whole packet was complete. Unbound version 1.21.1 introduces a hard limit on the number of name compression calculations it is willing to do per packet. Packets that need more compression will result in semi-compressed packets or truncated packets, even on TCP for huge messages, to avoid locking the CPU for long. This change should not affect normal DNS traffic.
CVE-2024-33655:The DNS protocol in RFC 1035 and updates allows remote attackers to cause a denial of service (resource consumption) by arranging for DNS queries to be accumulated for seconds, such that responses are later sent in a pulsing burst (which can be considered traffic amplification in some cases), aka the &quot;DNSBomb&quot; issue.
CVE-2024-43168:DISPUTE NOTE: this issue does not pose a security risk as it (according to analysis by the original software developer, NLnet Labs) falls within the expected functionality and security controls of the application. Red Hat has made a claim that there is a security risk within Red Hat products. NLnet Labs has no further information about the claim, and suggests that affected Red Hat customers refer to available Red Hat documentation or support channels. ORIGINAL DESCRIPTION: A heap-buffer-overflow flaw was found in the cfg_mark_ports function within Unbound's config_file.c, which can lead to memory corruption. This issue could allow an attacker with local access to provide specially crafted input, potentially causing the application to crash or allowing arbitrary code execution. This could result in a denial of service or unauthorized actions on the system.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="unbound" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-1.13.2-15.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-libs" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-15.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-devel" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-15.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="python3-unbound" release="15.u8.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-15.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="unbound-help" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-15.u8.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="unbound" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-1.13.2-15.u8.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-libs" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-libs-1.13.2-15.u8.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-devel" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-devel-1.13.2-15.u8.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="python3-unbound" release="15.u8.fos23" version="1.13.2">
					<filename>python3-unbound-1.13.2-15.u8.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="unbound-help" release="15.u8.fos23" version="1.13.2">
					<filename>unbound-help-1.13.2-15.u8.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2334</id>
		<title>An update for wireshark is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8645" id="CVE-2024-8645" title="CVE-2024-8645" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24476" id="CVE-2024-24476" title="CVE-2024-24476" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8250" id="CVE-2024-8250" title="CVE-2024-8250" type="cve"/>
		</references>
		<description>CVE-2024-8645:SPRT dissector crash in Wireshark 4.2.0 to 4.0.5 and 4.0.0 to 4.0.15 allows denial of service via packet injection or crafted capture file
CVE-2024-24476:A buffer overflow in Wireshark before 4.2.0 allows a remote attacker to cause a denial of service via the pan/addr_resolv.c, and ws_manuf_lookup_str(), size components. NOTE: this is disputed by the vendor because neither release 4.2.0 nor any other release was affected.
CVE-2024-8250:NTLMSSP dissector crash in Wireshark 4.2.0 to 4.0.6 and 4.0.0 to 4.0.16 allows denial of service via packet injection or crafted capture file</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="wireshark" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-11.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-devel" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-11.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="wireshark-help" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-11.u14.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-3.6.14-11.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-devel" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-devel-3.6.14-11.u14.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="wireshark-help" release="11.u14.fos23" version="3.6.14">
					<filename>wireshark-help-3.6.14-11.u14.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2335</id>
		<title>An update for wpa_supplicant is now available for FusionOS 23</title>
		<severity>Important</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5290" id="CVE-2024-5290" title="CVE-2024-5290" type="cve"/>
		</references>
		<description>CVE-2024-5290:An issue was discovered in Ubuntu wpa_supplicant that resulted in loading of arbitrary shared objects, which allows a local unprivileged attacker to escalate privileges to the user that wpa_supplicant runs as (usually root).
Membership in the netdev group or access to the dbus interface of wpa_supplicant allow an unprivileged user to specify an arbitrary path to a module to be loaded by the wpa_supplicant process; other escalation paths might exist.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="1" name="wpa_supplicant" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-2.6-32.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="wpa_supplicant-gui" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-gui-2.6-32.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="1" name="wpa_supplicant-help" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-help-2.6-32.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-2.6-32.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant-gui" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-gui-2.6-32.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="1" name="wpa_supplicant-help" release="32.u2.fos23" version="2.6">
					<filename>wpa_supplicant-help-2.6-32.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2336</id>
		<title>An update for xmlrpc-c is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45490" id="CVE-2024-45490" title="CVE-2024-45490" type="cve"/>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45491" id="CVE-2024-45491" title="CVE-2024-45491" type="cve"/>
		</references>
		<description>CVE-2024-45490:An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.
CVE-2024-45491:An issue was discovered in libexpat before 2.6.3. dtdCopy in xmlparse.c can have an integer overflow for nDefaultAtts on 32-bit platforms (where UINT_MAX equals SIZE_MAX).</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="xmlrpc-c" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-1.51.08-3.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="xmlrpc-c-devel" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-devel-1.51.08-3.u1.fos23.x86_64.rpm</filename>
				</package>
				<package arch="noarch" epoch="0" name="xmlrpc-c-help" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-help-1.51.08-3.u1.fos23.noarch.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="xmlrpc-c" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-1.51.08-3.u1.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="xmlrpc-c-devel" release="3.u1.fos23" version="1.51.08">
					<filename>xmlrpc-c-devel-1.51.08-3.u1.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
	<update from="xfusion.com" type="security" status="stable">
		<id>FusionOS-SA-2024-2337</id>
		<title>An update for xterm is now available for FusionOS 23</title>
		<severity>Critical</severity>
		<release>FusionOS</release>
		<issued date="2024-11-15"/>
		<references>
			<reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45063" id="CVE-2022-45063" title="CVE-2022-45063" type="cve"/>
		</references>
		<description>CVE-2022-45063:xterm before 375 allows code execution via font ops, e.g., because an OSC 50 response may have Ctrl-g and therefore lead to command execution within the vi line-editing mode of Zsh. NOTE: font ops are not allowed in the xterm default configurations of some Linux distributions.</description>
		<pkglist>
			<collection>
				<name>FusionOS</name>
				<package arch="x86_64" epoch="0" name="xterm" release="6.u2.fos23" version="363">
					<filename>xterm-363-6.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="x86_64" epoch="0" name="xterm-help" release="6.u2.fos23" version="363">
					<filename>xterm-help-363-6.u2.fos23.x86_64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="xterm" release="6.u2.fos23" version="363">
					<filename>xterm-363-6.u2.fos23.aarch64.rpm</filename>
				</package>
				<package arch="aarch64" epoch="0" name="xterm-help" release="6.u2.fos23" version="363">
					<filename>xterm-help-363-6.u2.fos23.aarch64.rpm</filename>
				</package>
			</collection>
		</pkglist>
	</update>
</updates>
