<?xml version="1.0" encoding="UTF-8"?>
<updates>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1001</id>
          <title>An update for patchelf is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44940" id="CVE-2022-44940" title="CVE-2022-44940" type="cve"></reference>
          </references>
          <description>Patchelf v0.9 was discovered to contain an out-of-bounds read via the function modifyRPath at src/patchelf.cc.(CVE-2022-44940)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="patchelf" release="1.oe2203sp1" version="0.16.0">
                         <filename>patchelf-0.16.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="patchelf-debuginfo" release="1.oe2203sp1" version="0.16.0">
                         <filename>patchelf-debuginfo-0.16.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="patchelf-debugsource" release="1.oe2203sp1" version="0.16.0">
                         <filename>patchelf-debugsource-0.16.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="patchelf-debuginfo" release="1.oe2203sp1" version="0.16.0">
                         <filename>patchelf-debuginfo-0.16.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="patchelf-debugsource" release="1.oe2203sp1" version="0.16.0">
                         <filename>patchelf-debugsource-0.16.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="patchelf" release="1.oe2203sp1" version="0.16.0">
                         <filename>patchelf-0.16.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1002</id>
          <title>An update for rubygem-dalli is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4064" id="CVE-2022-4064" title="CVE-2022-4064" type="cve"></reference>
          </references>
          <description>A vulnerability was found in Dalli. It has been classified as problematic. Affected is the function self.meta_set of the file lib/dalli/protocol/meta/request_formatter.rb of the component Meta Protocol Handler. The manipulation leads to injection. The exploit has been disclosed to the public and may be used. The name of the patch is 48d594dae55934476fec61789e7a7c3700e0f50d. It is recommended to apply a patch to fix this issue. VDB-214026 is the identifier assigned to this vulnerability.(CVE-2022-4064)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rubygem-dalli-doc" release="2.oe2203sp1" version="3.2.2">
                         <filename>rubygem-dalli-doc-3.2.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-dalli" release="2.oe2203sp1" version="3.2.2">
                         <filename>rubygem-dalli-3.2.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1003</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33621" id="CVE-2021-33621" title="CVE-2021-33621" type="cve"></reference>
          </references>
          <description>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.(CVE-2021-33621)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="rubygem-psych" release="128.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="128.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="128.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="128.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="128.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="128.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="128.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="128.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="128.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="128.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="128.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="128.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="128.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-power_assert" release="128.oe2203sp1" version="1.2.0">
                         <filename>rubygem-power_assert-1.2.0-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="128.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="128.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="128.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-128.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="128.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-128.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="128.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="128.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="128.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="128.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="128.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="128.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-128.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1004</id>
          <title>An update for python-setuptools is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40897" id="CVE-2022-40897" title="CVE-2022-40897" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-40897)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-setuptools" release="5.oe2203sp1" version="59.4.0">
                         <filename>python-setuptools-59.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-setuptools-help" release="5.oe2203sp1" version="59.4.0">
                         <filename>python-setuptools-help-59.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-setuptools" release="5.oe2203sp1" version="59.4.0">
                         <filename>python3-setuptools-59.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1008</id>
          <title>An update for libtar is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33640" id="CVE-2021-33640" title="CVE-2021-33640" type="cve"></reference>
          </references>
          <description>After tar_close(), libtar.c releases the memory pointed to by pointer t. After tar_close() is called in the list() function, it continues to use pointer t: free_longlink_longname(t-&gt;th_buf) . As a result, the released memory is used (use-after-free).(CVE-2021-33640)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtar-debuginfo" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-debuginfo-1.2.20-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtar-debugsource" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-debugsource-1.2.20-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtar-help" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-help-1.2.20-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtar-devel" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-devel-1.2.20-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtar" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-1.2.20-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtar-help" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-help-1.2.20-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtar-devel" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-devel-1.2.20-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtar" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-1.2.20-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtar-debugsource" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-debugsource-1.2.20-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtar-debuginfo" release="22.oe2203sp1" version="1.2.20">
                         <filename>libtar-debuginfo-1.2.20-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1009</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32547" id="CVE-2022-32547" title="CVE-2022-32547" type="cve"></reference>
          </references>
          <description>In ImageMagick, there is load of misaligned address for type &#39;double&#39;, which requires 8 byte alignment and for type &#39;float&#39;, which requires 4 byte alignment at MagickCore/property.c. Whenever crafted or untrusted input is processed by ImageMagick, this causes a negative impact to application availability or other problems related to undefined behavior.(CVE-2022-32547)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-perl-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-help-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-c++-devel-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-debugsource-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-devel-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-c++-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-debuginfo-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-debuginfo-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-c++-devel-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-devel-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-perl-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-c++-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-help-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-debugsource-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1010</id>
          <title>An update for net-snmp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44793" id="CVE-2022-44793" title="CVE-2022-44793" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44792" id="CVE-2022-44792" title="CVE-2022-44792" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-44793) 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-44792)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="net-snmp-help" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-help-5.9.1-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="net-snmp-debugsource" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-debugsource-5.9.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="python3-net-snmp" release="5.oe2203sp1" version="5.9.1">
                         <filename>python3-net-snmp-5.9.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="net-snmp-gui" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-gui-5.9.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="net-snmp-debuginfo" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-debuginfo-5.9.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="net-snmp" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-5.9.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="net-snmp-perl" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-perl-5.9.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="net-snmp-devel" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-devel-5.9.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="net-snmp-libs" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-libs-5.9.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="net-snmp-debuginfo" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-debuginfo-5.9.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="net-snmp-perl" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-perl-5.9.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="net-snmp-devel" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-devel-5.9.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="net-snmp-debugsource" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-debugsource-5.9.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="python3-net-snmp" release="5.oe2203sp1" version="5.9.1">
                         <filename>python3-net-snmp-5.9.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="net-snmp-libs" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-libs-5.9.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="net-snmp-gui" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-gui-5.9.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="net-snmp" release="5.oe2203sp1" version="5.9.1">
                         <filename>net-snmp-5.9.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1015</id>
          <title>An update for ppp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4603" id="CVE-2022-4603" title="CVE-2022-4603" type="cve"></reference>
          </references>
          <description>** 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.(CVE-2022-4603)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="ppp-help" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-help-2.4.9-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ppp" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-2.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ppp-devel" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-devel-2.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ppp-debugsource" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-debugsource-2.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ppp-debuginfo" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-debuginfo-2.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ppp-debugsource" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-debugsource-2.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ppp-debuginfo" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-debuginfo-2.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ppp" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-2.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ppp-devel" release="3.oe2203sp1" version="2.4.9">
                         <filename>ppp-devel-2.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1019</id>
          <title>An update for samba is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37966" id="CVE-2022-37966" title="CVE-2022-37966" type="cve"></reference>
          </references>
          <description>Windows Kerberos RC4-HMAC Elevation of Privilege Vulnerability.(CVE-2022-37966)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libsmbclient" release="5.oe2203sp1" version="4.17.2">
                         <filename>libsmbclient-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient" release="5.oe2203sp1" version="4.17.2">
                         <filename>libwbclient-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-modules" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-modules-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-usershares" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-usershares-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-dc" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-dc-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debugsource" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-debugsource-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-test" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-test-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-krb5-printing" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-krb5-printing-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-devel-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-clients" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-clients-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-common-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common-tools" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-common-tools-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-bind-dlz" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-bind-dlz-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debuginfo" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-debuginfo-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-help" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-help-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ctdb" release="5.oe2203sp1" version="4.17.2">
                         <filename>ctdb-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-libs" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-libs-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="samba-pidl" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-pidl-4.17.2-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-provision" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-provision-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>libwbclient-devel-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-client" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-client-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-krb5-locator" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-krb5-locator-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>libsmbclient-devel-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-test" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-test-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-modules" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-modules-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-dc" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-dc-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient" release="5.oe2203sp1" version="4.17.2">
                         <filename>libsmbclient-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>libwbclient-devel-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debuginfo" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-debuginfo-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-krb5-printing" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-krb5-printing-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-clients" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-clients-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-test" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-test-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-devel-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-test" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-test-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-krb5-locator" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-krb5-locator-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-provision" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-provision-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-vfs-glusterfs" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-vfs-glusterfs-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common-tools" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-common-tools-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-client" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-client-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-bind-dlz" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-bind-dlz-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-help" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-help-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>libsmbclient-devel-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ctdb" release="5.oe2203sp1" version="4.17.2">
                         <filename>ctdb-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-libs" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-libs-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debugsource" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-debugsource-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient" release="5.oe2203sp1" version="4.17.2">
                         <filename>libwbclient-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-common-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-usershares" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-usershares-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1020</id>
          <title>An update for kubernetes is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-25743" id="CVE-2021-25743" title="CVE-2021-25743" type="cve"></reference>
          </references>
          <description>kubectl does not neutralize escape, meta or control sequences contained in the raw data it outputs to a terminal. This includes but is not limited to the unstructured string fields in objects such as Events.(CVE-2021-25743)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kubernetes" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-1.20.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-client" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-client-1.20.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-help" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-help-1.20.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-master" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-master-1.20.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-node" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-node-1.20.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-kubelet" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubelet-1.20.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-kubeadm" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubeadm-1.20.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-client" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-client-1.20.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-kubelet" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubelet-1.20.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-node" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-node-1.20.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-1.20.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-help" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-help-1.20.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-master" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-master-1.20.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-kubeadm" release="16.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubeadm-1.20.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1021</id>
          <title>An update for jetty is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2048" id="CVE-2022-2048" title="CVE-2022-2048" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2047" id="CVE-2022-2047" title="CVE-2022-2047" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-2048) 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-2047)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jetty-http2-server" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-http2-server-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-osgi-boot-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-http-client-transport" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-http2-http-client-transport-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-hpack" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-http2-hpack-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-alpn" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-osgi-alpn-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javax-websocket-server-impl" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-javax-websocket-server-impl-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot-warurl" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-osgi-boot-warurl-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jndi" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-jndi-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-alpn-client" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-alpn-client-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-deploy" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-deploy-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-project" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-project-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-start" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-start-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-client" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-websocket-client-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-common" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-http2-common-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-osgi-boot-jsp" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-osgi-boot-jsp-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-server" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-websocket-server-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-servlets" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-servlets-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-servlet" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-websocket-servlet-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-util" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-util-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jmx" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-jmx-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-webapp" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-webapp-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-httpservice" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-httpservice-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jspc-maven-plugin" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-jspc-maven-plugin-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-client" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-client-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-fcgi-client" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-fcgi-client-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-spring" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-spring-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javax-websocket-client-impl" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-javax-websocket-client-impl-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-servlet" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-servlet-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jsp" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-jsp-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jstl" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-jstl-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-io" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-io-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-rewrite" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-rewrite-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-security" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-security-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-continuation" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-continuation-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-alpn-server" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-alpn-server-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-ant" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-ant-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jaspi" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-jaspi-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-api" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-websocket-api-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-annotations" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-annotations-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-cdi" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-cdi-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-fcgi-server" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-fcgi-server-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-http-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-plus" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-plus-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-nosql" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-nosql-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-xml" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-xml-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-proxy" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-proxy-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-util-ajax" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-util-ajax-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http-spi" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-http-spi-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-javadoc" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-javadoc-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-quickstart" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-quickstart-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-maven-plugin" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-maven-plugin-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-server" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-server-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-websocket-common" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-websocket-common-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-unixsocket" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-unixsocket-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-http2-client" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-http2-client-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-jaas" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-jaas-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jetty-infinispan" release="3.oe2203sp1" version="9.4.16">
                         <filename>jetty-infinispan-9.4.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1022</id>
          <title>An update for freeradius is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41860" id="CVE-2022-41860" title="CVE-2022-41860" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41861" id="CVE-2022-41861" title="CVE-2022-41861" type="cve"></reference>
          </references>
          <description>When an EAP-SIM supplicant sends an unknown SIM option, the server will try to look that option up in the internal dictionaries. This lookup will fail, but the SIM code will not check for that failure. Instead, it will dereference a NULL pointer, and cause the server to crash.References:https://freeradius.org/security/Upstream fix:https://github.com/FreeRADIUS/freeradius-server/commit/f1cdbb33ec61c4a64a(CVE-2022-41860) A malicious RADIUS client or home server can send a malformed abinary attribute which can cause the server to crash.References:https://freeradius.org/security/Upstream fix:https://github.com/FreeRADIUS/freeradius-server/commit/0ec2b39d260e(CVE-2022-41861)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="freeradius-sqlite" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-sqlite-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-help" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-help-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-devel" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-devel-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-utils" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-utils-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-ldap" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-ldap-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-debuginfo" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-debuginfo-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-mysql" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-mysql-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-freeradius" release="2.oe2203sp1" version="3.0.25">
                         <filename>python3-freeradius-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-debugsource" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-debugsource-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-postgresql" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-postgresql-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-perl" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-perl-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-krb5" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-krb5-3.0.25-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-mysql" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-mysql-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-freeradius" release="2.oe2203sp1" version="3.0.25">
                         <filename>python3-freeradius-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-devel" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-devel-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-sqlite" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-sqlite-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-postgresql" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-postgresql-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-help" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-help-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-debuginfo" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-debuginfo-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-debugsource" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-debugsource-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-ldap" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-ldap-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-krb5" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-krb5-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-utils" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-utils-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-perl" release="2.oe2203sp1" version="3.0.25">
                         <filename>freeradius-perl-3.0.25-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1023</id>
          <title>An update for php is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37454" id="CVE-2022-37454" title="CVE-2022-37454" type="cve"></reference>
          </references>
          <description>The Keccak XKCP SHA-3 reference implementation before fdc6fef has an integer overflow and resultant buffer overflow that allows attackers to execute arbitrary code or eliminate expected cryptographic properties. This occurs in the sponge function interface.(CVE-2022-37454)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="php-enchant" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-enchant-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-odbc-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-mysqlnd-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-snmp-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-ffi-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-pgsql-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-xml" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-xml-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gd" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-gd-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-mbstring-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-process-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-dba-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-tidy-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-common-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-sodium-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-cli-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-fpm-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-debuginfo-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-help" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-help-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-bcmath-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-dbg-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-ldap-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-opcache-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-devel-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-intl-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-pdo-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-gmp-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-debugsource-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-soap" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-soap-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-embedded-8.0.28-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-odbc-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-bcmath-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-xml-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-tidy-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-embedded-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-mbstring-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-help" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-help-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-ldap-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-enchant-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-fpm-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-cli-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-gd-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-debugsource-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-devel-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-gmp-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-mysqlnd-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-sodium-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-pgsql-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-common-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-intl-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-dba-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-dbg-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-debuginfo-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-ffi-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-process-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-snmp-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-soap-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-pdo-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="1.oe2203sp1" version="8.0.28">
                         <filename>php-opcache-8.0.28-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1024</id>
          <title>An update for python-pillow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45199" id="CVE-2022-45199" title="CVE-2022-45199" type="cve"></reference>
          </references>
          <description>Pillow before 9.3.0 allows denial of service via SAMPLESPERPIXEL.(CVE-2022-45199)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-pillow-devel" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debugsource" release="3.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debuginfo" release="3.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pillow-help" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-help-9.0.1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-tk" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-qt" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-qt" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-tk" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debugsource" release="3.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debuginfo" release="3.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-devel" release="3.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1025</id>
          <title>An update for openvswitch is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-01-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4338" id="CVE-2022-4338" title="CVE-2022-4338" type="cve"></reference>
          </references>
          <description>An integer underflow in Organization Specific TLV was found in various versions of OpenvSwitch.(CVE-2022-4338)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openvswitch-debugsource" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-devel" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-help" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-debuginfo" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debuginfo" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debugsource" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-help" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-devel" release="2.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1026</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0049" id="CVE-2023-0049" title="CVE-2023-0049" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0051" id="CVE-2023-0051" title="CVE-2023-0051" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0054" id="CVE-2023-0054" title="CVE-2023-0054" type="cve"></reference>
          </references>
          <description>Out-of-bounds Read in GitHub repository vim/vim prior to 9.0.1143.(CVE-2023-0049)Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1144.(CVE-2023-0051)Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.1145.(CVE-2023-0054)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="7.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="7.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="7.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="7.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="7.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="7.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="7.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="7.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="7.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="7.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="7.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="7.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="7.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1027</id>
          <title>An update for systemd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-01-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4415" id="CVE-2022-4415" title="CVE-2022-4415" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-4415)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="systemd-resolved" release="44.oe2203sp1" version="249">
                         <filename>systemd-resolved-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-networkd" release="44.oe2203sp1" version="249">
                         <filename>systemd-networkd-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-nspawn" release="44.oe2203sp1" version="249">
                         <filename>systemd-nspawn-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-udev" release="44.oe2203sp1" version="249">
                         <filename>systemd-udev-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-pam" release="44.oe2203sp1" version="249">
                         <filename>systemd-pam-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-libs" release="44.oe2203sp1" version="249">
                         <filename>systemd-libs-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-debugsource" release="44.oe2203sp1" version="249">
                         <filename>systemd-debugsource-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd" release="44.oe2203sp1" version="249">
                         <filename>systemd-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-debuginfo" release="44.oe2203sp1" version="249">
                         <filename>systemd-debuginfo-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-devel" release="44.oe2203sp1" version="249">
                         <filename>systemd-devel-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-container" release="44.oe2203sp1" version="249">
                         <filename>systemd-container-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-timesyncd" release="44.oe2203sp1" version="249">
                         <filename>systemd-timesyncd-249-44.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="systemd-help" release="44.oe2203sp1" version="249">
                         <filename>systemd-help-249-44.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-debuginfo" release="44.oe2203sp1" version="249">
                         <filename>systemd-debuginfo-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-udev" release="44.oe2203sp1" version="249">
                         <filename>systemd-udev-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-networkd" release="44.oe2203sp1" version="249">
                         <filename>systemd-networkd-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-pam" release="44.oe2203sp1" version="249">
                         <filename>systemd-pam-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-nspawn" release="44.oe2203sp1" version="249">
                         <filename>systemd-nspawn-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-devel" release="44.oe2203sp1" version="249">
                         <filename>systemd-devel-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-libs" release="44.oe2203sp1" version="249">
                         <filename>systemd-libs-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd" release="44.oe2203sp1" version="249">
                         <filename>systemd-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-container" release="44.oe2203sp1" version="249">
                         <filename>systemd-container-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-resolved" release="44.oe2203sp1" version="249">
                         <filename>systemd-resolved-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-debugsource" release="44.oe2203sp1" version="249">
                         <filename>systemd-debugsource-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-timesyncd" release="44.oe2203sp1" version="249">
                         <filename>systemd-timesyncd-249-44.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1029</id>
          <title>An update for SDL2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-01-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4743" id="CVE-2022-4743" title="CVE-2022-4743" type="cve"></reference>
          </references>
          <description>A memory leak issue was discovered in SDL2 version &gt;= SDL2-2.0.8See the link below for details:https://github.com/libsdl-org/SDL/pull/6269https://github.com/libsdl-org/SDL/commit/00b67f55727bc0944c3266e2b875440da132ce4b(CVE-2022-4743)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="SDL2-devel" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-devel-2.0.12-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="SDL2-debugsource" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-debugsource-2.0.12-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="SDL2" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-2.0.12-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="SDL2-debuginfo" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-debuginfo-2.0.12-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="SDL2-static" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-static-2.0.12-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="SDL2-devel" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-devel-2.0.12-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="SDL2" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-2.0.12-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="SDL2-debugsource" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-debugsource-2.0.12-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="SDL2-debuginfo" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-debuginfo-2.0.12-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="SDL2-static" release="5.oe2203sp1" version="2.0.12">
                         <filename>SDL2-static-2.0.12-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1033</id>
          <title>An update for byacc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-01-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33641" id="CVE-2021-33641" title="CVE-2021-33641" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33642" id="CVE-2021-33642" title="CVE-2021-33642" type="cve"></reference>
          </references>
          <description>No description is available for this CVE.(CVE-2021-33641)No description is available for this CVE.(CVE-2021-33642)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="byacc-debugsource" release="4.oe2203sp1" version="2.0.20210808">
                         <filename>byacc-debugsource-2.0.20210808-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="byacc-debuginfo" release="4.oe2203sp1" version="2.0.20210808">
                         <filename>byacc-debuginfo-2.0.20210808-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="byacc" release="4.oe2203sp1" version="2.0.20210808">
                         <filename>byacc-2.0.20210808-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="byacc-help" release="4.oe2203sp1" version="2.0.20210808">
                         <filename>byacc-help-2.0.20210808-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="byacc-debugsource" release="4.oe2203sp1" version="2.0.20210808">
                         <filename>byacc-debugsource-2.0.20210808-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="byacc-debuginfo" release="4.oe2203sp1" version="2.0.20210808">
                         <filename>byacc-debuginfo-2.0.20210808-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="byacc" release="4.oe2203sp1" version="2.0.20210808">
                         <filename>byacc-2.0.20210808-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1036</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2873" id="CVE-2022-2873" title="CVE-2022-2873" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3903" id="CVE-2022-3903" title="CVE-2022-3903" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3108" id="CVE-2022-3108" title="CVE-2022-3108" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3114" id="CVE-2022-3114" title="CVE-2022-3114" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2196" id="CVE-2022-2196" title="CVE-2022-2196" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47942" id="CVE-2022-47942" title="CVE-2022-47942" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47940" id="CVE-2022-47940" title="CVE-2022-47940" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47943" id="CVE-2022-47943" title="CVE-2022-47943" type="cve"></reference>
          </references>
          <description>An out-of-bounds memory access flaw was found in the Linux kernel Intel’s iSMT SMBus host controller driver in the way a user triggers the I2C_SMBUS_BLOCK_DATA (with the ioctl I2C_SMBUS) with malicious input data. This flaw allows a local user to crash the system.(CVE-2022-2873)An incorrect read request flaw was found in the Infrared Transceiver USB driver in the Linux kernel. This issue occurs when a user attaches a malicious USB device. A local user could use this flaw to starve the resources, causing denial of service or potentially crashing the system.(CVE-2022-3903)An issue was discovered in the Linux kernel through 5.16-rc6. kfd_parse_subtype_iolink in drivers/gpu/drm/amd/amdkfd/kfd_crat.c lacks check of the return value of kmemdup().(CVE-2022-3108)An issue was discovered in the Linux kernel through 5.16-rc6. imx_register_uart_clocks in drivers/clk/imx/clk.c lacks check of the return value of kcalloc() and will cause the null pointer dereference.(CVE-2022-3114)A regression exists in the Linux Kernel within KVM: nVMX that allowed for speculative execution attacks. L2 can carry out Spectre v2 attacks on L1 due to L1 thinking it doesn&#39;t need retpolines or IBPB after running L2 due to KVM (L0) advertising eIBRS support to L1. An attacker at L2 with code execution can execute code on an indirect branch on the host machine. We recommend upgrading to Kernel 6.2 or past commit 2e7eab81425a(CVE-2022-2196)An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is a heap-based buffer overflow in set_ntacl_dacl, related to use of SMB2_QUERY_INFO_HE after a malformed SMB2_SET_INFO_HE command.(CVE-2022-47942)An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.18 before 5.18.18. fs/ksmbd/smb2pdu.c lacks length validation in the non-padding case in smb2_write.(CVE-2022-47940)An issue was discovered in ksmbd in the Linux kernel 5.15 through 5.19 before 5.19.2. There is an out-of-bounds read and OOPS for SMB2_WRITE, when there is a large length in the zero DataOffset case.(CVE-2022-47943)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.14.2.90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.14.2.90.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.14.2.90.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1039</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-01-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3424" id="CVE-2022-3424" title="CVE-2022-3424" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4662" id="CVE-2022-4662" title="CVE-2022-4662" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47946" id="CVE-2022-47946" title="CVE-2022-47946" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4842" id="CVE-2022-4842" title="CVE-2022-4842" type="cve"></reference>
          </references>
          <description>A use-after-free flaw was found in the Linux kernel?s SGI GRU driver in the way the first gru_file_unlocked_ioctl function is called by the user, where a fail pass occurs in the gru_check_chiplet_assignment function. This flaw allows a local user to crash or potentially escalate their privileges on the system.(CVE-2022-3424)A flaw incorrect access control in the Linux kernel USB core subsystem was found in the way user attaches usb device. A local user could use this flaw to crash the system.(CVE-2022-4662)An issue was discovered in the Linux kernel 5.10.x before 5.10.155. A use-after-free in io_sqpoll_wait_sq in fs/io_uring.c allows an attacker to crash the kernel, resulting in denial of service. finish_wait can be skipped. An attack can occur in some situations by forking a process and then quickly terminating it. NOTE: later kernel versions, such as the 5.15 longterm series, substantially changed the implementation of io_sqpoll_wait_sq.(CVE-2022-47946)A flaw NULL Pointer Dereference in the Linux kernel NTFS3 driver function attr_punch_hole() was found. A local user could use this flaw to crash the system.(CVE-2022-4842)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-headers" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.15.0.91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.15.0.91.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.15.0.91.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1044</id>
          <title>An update for git is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-02-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23521" id="CVE-2022-23521" title="CVE-2022-23521" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41903" id="CVE-2022-41903" title="CVE-2022-41903" type="cve"></reference>
          </references>
          <description>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-23521)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-41903)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="git" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-daemon" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debuginfo" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-core" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debugsource" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gitk" release="7.oe2203sp1" version="2.33.0">
                         <filename>gitk-2.33.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-svn" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-svn-2.33.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-gui" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-gui-2.33.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-web" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-web-2.33.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git" release="7.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-2.33.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-help" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-help-2.33.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git-SVN" release="7.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-SVN-2.33.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-email" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-email-2.33.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debugsource" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-daemon" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-core" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debuginfo" release="7.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1046</id>
          <title>An update for pkgconf is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24056" id="CVE-2023-24056" title="CVE-2023-24056" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-24056)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pkgconf" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-1.8.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pkgconf-devel" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-devel-1.8.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pkgconf-debuginfo" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-debuginfo-1.8.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pkgconf-debugsource" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-debugsource-1.8.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="pkgconf-help" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-help-1.8.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pkgconf-devel" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-devel-1.8.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pkgconf-debuginfo" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-debuginfo-1.8.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pkgconf" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-1.8.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pkgconf-debugsource" release="3.oe2203sp1" version="1.8.0">
                         <filename>pkgconf-debugsource-1.8.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1047</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48281" id="CVE-2022-48281" title="CVE-2022-48281" type="cve"></reference>
          </references>
          <description>processCropSelections in tools/tiffcrop.c in LibTIFF through 4.5.0 has a heap-based buffer overflow (e.g., &#34;WRITE of size 307203&#34;) via a crafted TIFF image.(CVE-2022-48281)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-devel" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-tools" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1048</id>
          <title>An update for samba is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38023" id="CVE-2022-38023" title="CVE-2022-38023" type="cve"></reference>
          </references>
          <description>Netlogon RPC Elevation of Privilege Vulnerability.(CVE-2022-38023)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="samba-test" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-test-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>libsmbclient-devel-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-modules" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-modules-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient" release="5.oe2203sp1" version="4.17.2">
                         <filename>libwbclient-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-help" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-help-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-usershares" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-usershares-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-test" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-test-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-common-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common-tools" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-common-tools-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-dc" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-dc-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debuginfo" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-debuginfo-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-provision" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-provision-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-client" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-client-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>libwbclient-devel-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-bind-dlz" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-bind-dlz-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-devel-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-krb5-locator" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-krb5-locator-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ctdb" release="5.oe2203sp1" version="4.17.2">
                         <filename>ctdb-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient" release="5.oe2203sp1" version="4.17.2">
                         <filename>libsmbclient-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-libs" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-libs-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-clients" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-clients-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-krb5-printing" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-krb5-printing-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debugsource" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-debugsource-4.17.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="samba-pidl" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-pidl-4.17.2-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>libwbclient-devel-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-client" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-client-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-vfs-glusterfs" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-vfs-glusterfs-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-krb5-printing" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-krb5-printing-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-usershares" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-usershares-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common-tools" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-common-tools-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-dc" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-dc-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-test" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-test-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient" release="5.oe2203sp1" version="4.17.2">
                         <filename>libwbclient-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-help" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-help-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-bind-dlz" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-bind-dlz-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient" release="5.oe2203sp1" version="4.17.2">
                         <filename>libsmbclient-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba" release="5.oe2203sp1" version="4.17.2">
                         <filename>python3-samba-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>libsmbclient-devel-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-krb5-locator" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-krb5-locator-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-clients" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-clients-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-provision" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-dc-provision-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-common-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-devel" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-devel-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debugsource" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-debugsource-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-modules" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-winbind-modules-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-test" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-test-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debuginfo" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-debuginfo-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ctdb" release="5.oe2203sp1" version="4.17.2">
                         <filename>ctdb-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-libs" release="5.oe2203sp1" version="4.17.2">
                         <filename>samba-libs-4.17.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1049</id>
          <title>An update for sudo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22809" id="CVE-2023-22809" title="CVE-2023-22809" type="cve"></reference>
          </references>
          <description>In Sudo before 1.9.12p2, the sudoedit (aka -e) feature mishandles extra arguments passed in the user-provided environment variables (SUDO_EDITOR, VISUAL, and EDITOR), allowing a local attacker to append arbitrary entries to the list of files to process. This can lead to privilege escalation. Affected versions are 1.8.0 through 1.9.12.p1. The problem exists because a user-specified editor may contain a &#34;--&#34; argument that defeats a protection mechanism, e.g., an EDITOR=&#39;vim -- /path/to/extra/file&#39; value.(CVE-2023-22809)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sudo" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-1.9.8p2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-debuginfo" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debuginfo-1.9.8p2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-devel" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-devel-1.9.8p2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-debugsource" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debugsource-1.9.8p2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sudo-help" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-help-1.9.8p2-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-1.9.8p2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-debuginfo" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debuginfo-1.9.8p2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-debugsource" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debugsource-1.9.8p2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-devel" release="9.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-devel-1.9.8p2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1050</id>
          <title>An update for batik is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41704" id="CVE-2022-41704" title="CVE-2022-41704" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42890" id="CVE-2022-42890" title="CVE-2022-42890" type="cve"></reference>
          </references>
          <description>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-41704)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.(CVE-2022-42890)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="batik" release="7.oe2203sp1" version="1.10">
                         <filename>batik-1.10-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="batik-help" release="7.oe2203sp1" version="1.10">
                         <filename>batik-help-1.10-7.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1052</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36760" id="CVE-2022-36760" title="CVE-2022-36760" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37436" id="CVE-2022-37436" title="CVE-2022-37436" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2006-20001" id="CVE-2006-20001" title="CVE-2006-20001" type="cve"></reference>
          </references>
          <description>Inconsistent Interpretation of HTTP Requests (&#39;HTTP Request Smuggling&#39;) vulnerability in mod_proxy_ajp of Apache HTTP Server allows an attacker to smuggle requests to the AJP server it forwards requests to. This issue affects Apache HTTP Server Apache HTTP Server 2.4 version 2.4.54 and prior versions.(CVE-2022-36760)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-2022-37436)A carefully crafted If: request header can cause a memory read, or write of a single zero byte, in a pool (heap) memory location beyond the header value sent. This could cause the process to crash. This issue affects Apache HTTP Server 2.4.54 and earlier.(CVE-2006-20001)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="httpd-debugsource" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-help-2.4.51-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="13.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="13.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1053</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20928" id="CVE-2023-20928" title="CVE-2023-20928" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0210" id="CVE-2023-0210" title="CVE-2023-0210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23559" id="CVE-2023-23559" title="CVE-2023-23559" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4696" id="CVE-2022-4696" title="CVE-2022-4696" type="cve"></reference>
          </references>
          <description>In binder_vma_close of binder.c, there is a possible use after free due to improper locking. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-254837884References: Upstream kernel(CVE-2023-20928)A heap overflow bug in ksmbd_decode_ntlmssp_auth_blob in which nt_len can be less than CIFS_ENCPWD_SIZE. This results in a negative blen argument for ksmbd_auth_ntlmv2, where it calls memcpy using blen on memory allocated by kmalloc(blen + CIFS_CRYPTO_KEY_SIZE). Note that CIFS_ENCPWD_SIZE is 16 and CIFS_CRYPTO_KEY_SIZE is 8. We believe this bug can only result in a remote DOS and not privilege escalation nor RCE, as the heap overflow occurs when blen is in range (-8, -1].”Reference:https://securityonline.info/cve-2023-0210-flaw-in-linux-kernel-allows-unauthenticated-remote-dos-attacks/https://www.spinics.net/lists/stable-commits/msg282893.html(CVE-2023-0210)In rndis_query_oid in drivers/net/wireless/rndis_wlan.c in the Linux kernel through 6.1.5, there is an integer overflow in an addition.(CVE-2023-23559)There exists a use-after-free vulnerability in the Linux kernel through io_uring and the IORING_OP_SPLICE operation. If IORING_OP_SPLICE is missing the IO_WQ_WORK_FILES flag, which signals that the operation won&#39;t use current-&gt;nsproxy, so its reference counter is not increased. This assumption is not always true as calling io_splice on specific files will call the get_uts function which will use current-&gt;nsproxy leading to invalidly decreasing its reference counter later causing the use-after-free vulnerability. We recommend upgrading to version 5.10.160 or above(CVE-2022-4696)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-devel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-source" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1058</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42252" id="CVE-2022-42252" title="CVE-2022-42252" type="cve"></reference>
          </references>
          <description>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-2022-42252)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="29.oe2203sp1" version="9.0.10">
                         <filename>tomcat-jsvc-9.0.10-29.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="29.oe2203sp1" version="9.0.10">
                         <filename>tomcat-help-9.0.10-29.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat" release="29.oe2203sp1" version="9.0.10">
                         <filename>tomcat-9.0.10-29.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1059</id>
          <title>An update for git is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41953" id="CVE-2022-41953" title="CVE-2022-41953" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-41953)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="git" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debuginfo" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-core" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debugsource" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-daemon" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-help" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-help-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-web" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-web-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-email" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-email-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git" release="9.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="gitk" release="9.oe2203sp1" version="2.33.0">
                         <filename>gitk-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-svn" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-svn-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git-SVN" release="9.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-SVN-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-gui" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-gui-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-daemon" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-core" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debuginfo" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debugsource" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1061</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0288" id="CVE-2023-0288" title="CVE-2023-0288" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47024" id="CVE-2022-47024" title="CVE-2022-47024" type="cve"></reference>
          </references>
          <description>Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1189.(CVE-2023-0288)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-2022-47024)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-common" release="8.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="8.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="8.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="8.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="8.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="8.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="8.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="8.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="8.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="8.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="8.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="8.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="8.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1062</id>
          <title>An update for opusfile is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47021" id="CVE-2022-47021" title="CVE-2022-47021" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-47021)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="opusfile" release="5.oe2203sp1" version="0.11">
                         <filename>opusfile-0.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="opusfile-devel" release="5.oe2203sp1" version="0.11">
                         <filename>opusfile-devel-0.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="opusfile-debuginfo" release="5.oe2203sp1" version="0.11">
                         <filename>opusfile-debuginfo-0.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="opusfile-debugsource" release="5.oe2203sp1" version="0.11">
                         <filename>opusfile-debugsource-0.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opusfile-debugsource" release="5.oe2203sp1" version="0.11">
                         <filename>opusfile-debugsource-0.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opusfile-debuginfo" release="5.oe2203sp1" version="0.11">
                         <filename>opusfile-debuginfo-0.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opusfile-devel" release="5.oe2203sp1" version="0.11">
                         <filename>opusfile-devel-0.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opusfile" release="5.oe2203sp1" version="0.11">
                         <filename>opusfile-0.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1064</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25136" id="CVE-2023-25136" title="CVE-2023-25136" type="cve"></reference>
          </references>
          <description>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 triggered by an unauthenticated attacker in the default configuration. One third-party report states &#34;remote code execution is theoretically possible.&#34;(CVE-2023-25136)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.18.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debuginfo" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-server" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-help-8.8p1-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.18.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="18.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1065</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44267" id="CVE-2022-44267" title="CVE-2022-44267" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44268" id="CVE-2022-44268" title="CVE-2022-44268" type="cve"></reference>
          </references>
          <description>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-44267)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).(CVE-2022-44268)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-c++-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-debugsource-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-perl-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-debuginfo-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-devel-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-help-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-c++-devel-7.1.0.28-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-c++-devel-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-c++-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-perl-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-debugsource-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-debuginfo-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-devel-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="6.oe2203sp1" version="7.1.0.28">
                         <filename>ImageMagick-help-7.1.0.28-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1066</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0433" id="CVE-2023-0433" title="CVE-2023-0433" type="cve"></reference>
          </references>
          <description>Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1225.(CVE-2023-0433)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="9.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="9.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="9.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="9.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="9.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="9.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="9.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="9.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="9.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="9.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="9.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="9.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="9.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1068</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3094" id="CVE-2022-3094" title="CVE-2022-3094" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3736" id="CVE-2022-3736" title="CVE-2022-3736" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3924" id="CVE-2022-3924" title="CVE-2022-3924" type="cve"></reference>
          </references>
          <description>Sending a flood of dynamic DNS updates may cause `named` to allocate large amounts of memory. This, in turn, may cause `named` to exit due to a lack of free memory. We are not aware of any cases where this has been exploited. Memory is allocated prior to the checking of access permissions (ACLs) and is retained during the processing of a dynamic update from a client whose access credentials are accepted. Memory allocated to clients that are not permitted to send updates is released immediately upon rejection. The scope of this vulnerability is limited therefore to trusted clients who are permitted to make dynamic zone changes. If a dynamic update is REFUSED, memory will be released again very quickly. Therefore it is only likely to be possible to degrade or stop `named` by sending a flood of unaccepted dynamic updates comparable in magnitude to a query flood intended to achieve the same detrimental outcome. BIND 9.11 and earlier branches are also affected, but through exhaustion of internal resources rather than memory constraints. This may reduce performance but should not be a significant problem for most servers. Therefore we don&#39;t intend to address this for BIND versions prior to BIND 9.16. This issue affects BIND 9 versions 9.16.0 through 9.16.36, 9.18.0 through 9.18.10, 9.19.0 through 9.19.8, and 9.16.8-S1 through 9.16.36-S1.(CVE-2022-3094)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-3736)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-3924)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="3" arch="aarch64" name="bind-pkcs11-utils" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-dnssec-utils" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-chroot" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-pkcs11-devel" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-pkcs11-libs" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-debugsource" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-devel" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-debuginfo" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-libs" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-utils" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="bind-pkcs11" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="noarch" name="bind-license" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-license-9.16.23-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="3" arch="noarch" name="python3-bind" release="15.oe2203sp1" version="9.16.23">
                         <filename>python3-bind-9.16.23-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="3" arch="noarch" name="bind-dnssec-doc" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-dnssec-utils" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-chroot" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-pkcs11" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-debuginfo" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-debugsource" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-pkcs11-utils" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-libs" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-devel" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-pkcs11-devel" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-pkcs11-libs" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="bind-utils" release="15.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1070</id>
          <title>An update for tmux is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47016" id="CVE-2022-47016" title="CVE-2022-47016" type="cve"></reference>
          </references>
          <description>A null pointer dereference issue was discovered in function window_pane_set_event in window.c in tmux 3.0 thru 3.3 and later, allows attackers to cause denial of service or other unspecified impacts.(CVE-2022-47016)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="tmux-debuginfo" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-debuginfo-3.2a-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tmux-debugsource" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-debugsource-3.2a-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tmux" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-3.2a-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tmux-debuginfo" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-debuginfo-3.2a-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tmux-debugsource" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-debugsource-3.2a-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tmux" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-3.2a-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="tmux-help" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-help-3.2a-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="tmux-help" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-help-3.2a-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tmux-debuginfo" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-debuginfo-3.2a-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tmux-debugsource" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-debugsource-3.2a-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tmux" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-3.2a-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tmux-debuginfo" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-debuginfo-3.2a-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tmux-debugsource" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-debugsource-3.2a-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tmux" release="3.oe2203sp1" version="3.2a">
                         <filename>tmux-3.2a-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1072</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0179" id="CVE-2023-0179" title="CVE-2023-0179" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23455" id="CVE-2023-23455" title="CVE-2023-23455" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23454" id="CVE-2023-23454" title="CVE-2023-23454" type="cve"></reference>
          </references>
          <description>A buffer overflow vulnerability was found in the Netfilter subsystem in the Linux Kernel. This issue could allow the leakage of both stack and heap addresses, and potentially allow Local Privilege Escalation to the root user via arbitrary code execution.(CVE-2023-0179)atm_tc_enqueue in net/sched/sch_atm.c in the Linux kernel through 6.1.4 allows attackers to cause a denial of service because of type confusion (non-negative numbers can sometimes indicate a TC_ACT_SHOT condition rather than valid classification results).(CVE-2023-23455)cbq_classify in net/sched/sch_cbq.c in the Linux kernel through 6.1.4 allows attackers to cause a denial of service (slab-out-of-bounds read) because of type confusion (non-negative numbers can sometimes indicate a TC_ACT_SHOT condition rather than valid classification results).(CVE-2023-23454)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="kernel-source" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.17.0.93.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.17.0.93.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.17.0.93.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1077</id>
          <title>An update for lxc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47952" id="CVE-2022-47952" title="CVE-2022-47952" type="cve"></reference>
          </references>
          <description>lxc-user-nic in lxc through 5.0.1 is installed setuid root, and may allow local users to infer whether any file exists, even within a protected directory tree, because &#34;Failed to open&#34; often indicates that a file does not exist, whereas &#34;does not refer to a network namespace path&#34; often indicates that a file exists. NOTE: this is different from CVE-2018-6556 because the CVE-2018-6556 fix design was based on the premise that &#34;we will report back to the user that the open() failed but the user has no way of knowing why it failed&#34;; however, in many realistic cases, there are no plausible reasons for failing except that the file does not exist.(CVE-2022-47952)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="lxc-devel" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-devel-4.0.3-2022102408.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lxc-libs" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-libs-4.0.3-2022102408.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lxc-debugsource" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-debugsource-4.0.3-2022102408.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lxc-debuginfo" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-debuginfo-4.0.3-2022102408.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lxc" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-4.0.3-2022102408.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="lxc-help" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-help-4.0.3-2022102408.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lxc-debuginfo" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-debuginfo-4.0.3-2022102408.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lxc-debugsource" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-debugsource-4.0.3-2022102408.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lxc-libs" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-libs-4.0.3-2022102408.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lxc" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-4.0.3-2022102408.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lxc-devel" release="2022102408.oe2203sp1" version="4.0.3">
                         <filename>lxc-devel-4.0.3-2022102408.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1078</id>
          <title>An update for libXpm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4883" id="CVE-2022-4883" title="CVE-2022-4883" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44617" id="CVE-2022-44617" title="CVE-2022-44617" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46285" id="CVE-2022-46285" title="CVE-2022-46285" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-4883)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-44617)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-46285)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libXpm" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-3.5.13-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libXpm-devel" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-devel-3.5.13-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libXpm-debugsource" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-debugsource-3.5.13-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libXpm-debuginfo" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-debuginfo-3.5.13-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libXpm-help" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-help-3.5.13-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libXpm-debuginfo" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-debuginfo-3.5.13-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libXpm-devel" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-devel-3.5.13-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libXpm" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-3.5.13-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libXpm-debugsource" release="4.oe2203sp1" version="3.5.13">
                         <filename>libXpm-debugsource-3.5.13-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1079</id>
          <title>An update for tpm2-tss is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22745" id="CVE-2023-22745" title="CVE-2023-22745" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-22745)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="tpm2-tss-devel" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-devel-3.1.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tpm2-tss-debuginfo" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-debuginfo-3.1.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tpm2-tss-debugsource" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-debugsource-3.1.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tpm2-tss" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-3.1.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="tpm2-tss-help" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-help-3.1.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tss-debuginfo" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-debuginfo-3.1.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tss-debugsource" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-debugsource-3.1.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tss-devel" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-devel-3.1.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tss" release="3.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-3.1.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1080</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41717" id="CVE-2022-41717" title="CVE-2022-41717" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-41717)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="14.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="14.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="14.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="14.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1106</id>
          <title>An update for tar is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48303" id="CVE-2022-48303" title="CVE-2022-48303" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-48303)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="tar-debuginfo" release="4.oe2203sp1" version="1.34">
                         <filename>tar-debuginfo-1.34-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="tar" release="4.oe2203sp1" version="1.34">
                         <filename>tar-1.34-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="tar-debugsource" release="4.oe2203sp1" version="1.34">
                         <filename>tar-debugsource-1.34-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="tar-help" release="4.oe2203sp1" version="1.34">
                         <filename>tar-help-1.34-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="tar-debugsource" release="4.oe2203sp1" version="1.34">
                         <filename>tar-debugsource-1.34-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="tar-debuginfo" release="4.oe2203sp1" version="1.34">
                         <filename>tar-debuginfo-1.34-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="tar" release="4.oe2203sp1" version="1.34">
                         <filename>tar-1.34-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1107</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
          </references>
          <description>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-0215)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-4304)The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &#34;name&#34; (e.g. &#34;CERTIFICATE&#34;), any header data and the payload data. If the function succeeds then the &#34;name_out&#34;, &#34;header&#34; and &#34;data&#34; arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. These locations include the PEM_read_bio_TYPE() functions as well as the decoders introduced in OpenSSL 3.0. The OpenSSL asn1parse command line application is also impacted by this issue.(CVE-2022-4450)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-0286)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="16.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1108</id>
          <title>An update for apr-util is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25147" id="CVE-2022-25147" title="CVE-2022-25147" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-25147)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="apr-util-devel" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-devel-1.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="apr-util-debugsource" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-debugsource-1.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="apr-util-pgsql" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-pgsql-1.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="apr-util" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-1.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="apr-util-odbc" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-odbc-1.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="apr-util-debuginfo" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-debuginfo-1.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-util-debuginfo" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-debuginfo-1.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-util-devel" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-devel-1.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-util-odbc" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-odbc-1.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-util-pgsql" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-pgsql-1.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-util" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-1.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-util-debugsource" release="14.oe2203sp1" version="1.6.1">
                         <filename>apr-util-debugsource-1.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1109</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3707" id="CVE-2022-3707" title="CVE-2022-3707" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0394" id="CVE-2023-0394" title="CVE-2023-0394" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0590" id="CVE-2023-0590" title="CVE-2023-0590" type="cve"></reference>
          </references>
          <description>A double-free memory flaw was found in the Linux kernel. The Intel GVT-g graphics driver triggers VGA card system resource overload, causing a fail in the intel_gvt_dma_map_guest_page function. This issue could allow a local user to crash the system.(CVE-2022-3707)A NULL pointer dereference flaw was found in rawv6_push_pending_frames in net/ipv6/raw.c in the network subcomponent in the Linux kernel. This flaw causes the system to crash.(CVE-2023-0394)A use-after-free flaw was found in qdisc_graft in net/sched/sch_api.c in the Linux Kernel due to a race problem leading to a denial-of-service problem. Reference:https://lore.kernel.org/all/20221018203258.2793282-1-edumazet@google.com/Crash:    BUG: KASAN: use-after-free in __tcf_qdisc_find.part.0+0xa3a/0xac0 net/sched/cls_api.c:1066    Read of size 4 at addr ffff88802065e038 by task syz-executor.4/21027        CPU: 0 PID: 21027 Comm: syz-executor.4 Not tainted 6.0.0-rc3-syzkaller-00363-g7726d4c3e60b #0    Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/26/2022    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 mm/kasan/report.c:317 [inline]    print_report.cold+0x2ba/0x719 mm/kasan/report.c:433    kasan_report+0xb1/0x1e0 mm/kasan/report.c:495    __tcf_qdisc_find.part.0+0xa3a/0xac0 net/sched/cls_api.c:1066    __tcf_qdisc_find net/sched/cls_api.c:1051 [inline]    tc_new_tfilter+0x34f/0x2200 net/sched/cls_api.c:2018    rtnetlink_rcv_msg+0x955/0xca0 net/core/rtnetlink.c:6081    netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2501    netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]    netlink_unicast+0x543/0x7f0 net/netlink/af_netlink.c:1345    netlink_sendmsg+0x917/0xe10 net/netlink/af_netlink.c:1921    sock_sendmsg_nosec net/socket.c:714 [inline]    sock_sendmsg+0xcf/0x120 net/socket.c:734    ____sys_sendmsg+0x6eb/0x810 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+0x35/0xb0 arch/x86/entry/common.c:80    entry_SYSCALL_64_after_hwframe+0x63/0xcd    RIP: 0033:0x7f5efaa89279(CVE-2023-0590)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-headers" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="kernel-devel" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.19.0.95.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.19.0.95.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.19.0.95.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1110</id>
          <title>An update for c-ares is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4904" id="CVE-2022-4904" title="CVE-2022-4904" type="cve"></reference>
          </references>
          <description>In ares_set_sortlist, it calls config_sortlist(..., sortstr) to parse the input str and initialize a sortlist configuration. However, ares_set_sortlist has not any checks about the validity of the input str. It is very easy to create an arbitrary length stack overflow with the unchecked memcpy(ipbuf, str, q-str); and memcpy(ipbufpfx, str, q-str); statements in the config_sortlist call, which could potentially cause severe security impact in practical programs.(CVE-2022-4904)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="c-ares-debuginfo" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-devel" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-debugsource" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="c-ares-help" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-help-1.18.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debuginfo" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debugsource" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-devel" release="4.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1111</id>
          <title>An update for harfbuzz is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25193" id="CVE-2023-25193" title="CVE-2023-25193" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-25193)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="harfbuzz-debuginfo" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-debuginfo-2.8.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="harfbuzz" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-2.8.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="harfbuzz-debugsource" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-debugsource-2.8.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="harfbuzz-devel" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-devel-2.8.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="harfbuzz-help" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-help-2.8.2-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="harfbuzz-debuginfo" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-debuginfo-2.8.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="harfbuzz" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-2.8.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="harfbuzz-debugsource" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-debugsource-2.8.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="harfbuzz-devel" release="4.oe2203sp1" version="2.8.2">
                         <filename>harfbuzz-devel-2.8.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1112</id>
          <title>An update for rubygem-globalid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22799" id="CVE-2023-22799" title="CVE-2023-22799" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-22799)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rubygem-globalid" release="4.oe2203sp1" version="0.4.2">
                         <filename>rubygem-globalid-0.4.2-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-globalid-doc" release="4.oe2203sp1" version="0.4.2">
                         <filename>rubygem-globalid-doc-0.4.2-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1113</id>
          <title>An update for python-cryptography is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23931" id="CVE-2023-23931" title="CVE-2023-23931" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-23931)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-cryptography-debuginfo" release="2.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-debuginfo-36.0.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-cryptography-debugsource" release="2.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-debugsource-36.0.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-cryptography" release="2.oe2203sp1" version="36.0.1">
                         <filename>python3-cryptography-36.0.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-cryptography-help" release="2.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-help-36.0.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-cryptography" release="2.oe2203sp1" version="36.0.1">
                         <filename>python3-cryptography-36.0.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-cryptography-debugsource" release="2.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-debugsource-36.0.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-cryptography-debuginfo" release="2.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-debuginfo-36.0.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1114</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23969" id="CVE-2023-23969" title="CVE-2023-23969" type="cve"></reference>
          </references>
          <description>In Django 3.2 before 3.2.17, 4.0 before 4.0.9, and 4.1 before 4.1.6, the parsed values of Accept-Language headers are cached in order to avoid repetitive parsing. This leads to a potential denial-of-service vector via excessive memory usage if the raw value of Accept-Language headers is very large.(CVE-2023-23969)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="1.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="1.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="2.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-django-help" release="2.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1115</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3724" id="CVE-2022-3724" title="CVE-2022-3724" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4344" id="CVE-2022-4344" title="CVE-2022-4344" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4345" id="CVE-2022-4345" title="CVE-2022-4345" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0413" id="CVE-2023-0413" title="CVE-2023-0413" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0417" id="CVE-2023-0417" title="CVE-2023-0417" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0415" id="CVE-2023-0415" title="CVE-2023-0415" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0411" id="CVE-2023-0411" title="CVE-2023-0411" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0412" id="CVE-2023-0412" title="CVE-2023-0412" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0416" id="CVE-2023-0416" title="CVE-2023-0416" type="cve"></reference>
          </references>
          <description>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-2022-3724)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-4344)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-2022-4345)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-0413)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-2023-0417)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-0415)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-0411)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-0412)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-0416)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="1.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1116</id>
          <title>An update for gssntlmssp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25564" id="CVE-2023-25564" title="CVE-2023-25564" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25565" id="CVE-2023-25565" title="CVE-2023-25565" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25567" id="CVE-2023-25567" title="CVE-2023-25567" type="cve"></reference>
          </references>
          <description>GSS-NTLMSSP is a mechglue plugin for the GSSAPI library that implements NTLM authentication. Prior to version 1.2.0, memory corruption can be triggered when decoding UTF16 strings. The variable `outlen` was not initialized and could cause writing a zero to an arbitrary place in memory if `ntlm_str_convert()` were to fail, which would leave `outlen` uninitialized. This can lead to a denial of service if the write hits unmapped memory or randomly corrupts a byte in the application memory space. This vulnerability can trigger an out-of-bounds write, leading to memory corruption. This vulnerability can be triggered via the main `gss_accept_sec_context` entry point. This issue is fixed in version 1.2.0.(CVE-2023-25564)GSS-NTLMSSP is a mechglue plugin for the GSSAPI library that implements NTLM authentication. Prior to version 1.2.0, an incorrect free when decoding target information can trigger a denial of service. The error condition incorrectly assumes the `cb` and `sh` buffers contain a copy of the data that needs to be freed. However, that is not the case. This vulnerability can be triggered via the main `gss_accept_sec_context` entry point. This will likely trigger an assertion failure in `free`, causing a denial-of-service. This issue is fixed in version 1.2.0.(CVE-2023-25565)GSS-NTLMSSP, a mechglue plugin for the GSSAPI library that implements NTLM authentication, has an out-of-bounds read when decoding target information prior to version 1.2.0. The length of the `av_pair` is not checked properly for two of the elements which can trigger an out-of-bound read. The out-of-bounds read can be triggered via the main `gss_accept_sec_context` entry point and could cause a denial-of-service if the memory is unmapped. The issue is fixed in version 1.2.0.(CVE-2023-25567)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gssntlmssp-debuginfo" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-debuginfo-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp-help" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-help-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp-debugsource" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-debugsource-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp-devel" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-devel-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp-debuginfo" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-debuginfo-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp-help" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-help-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp-debugsource" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-debugsource-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gssntlmssp-devel" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-devel-0.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp-help" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-help-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp-debuginfo" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-debuginfo-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp-debugsource" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-debugsource-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp-devel" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-devel-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp-help" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-help-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp-debuginfo" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-debuginfo-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp-debugsource" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-debugsource-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gssntlmssp-devel" release="10.oe2203sp1" version="0.7.0">
                         <filename>gssntlmssp-devel-0.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1117</id>
          <title>An update for apr is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24963" id="CVE-2022-24963" title="CVE-2022-24963" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-24963)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="apr-debuginfo" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-debuginfo-1.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="apr-devel" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-devel-1.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="apr-debugsource" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-debugsource-1.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="apr" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-1.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="apr-help" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-help-1.7.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-debuginfo" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-debuginfo-1.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-debugsource" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-debugsource-1.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr-devel" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-devel-1.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="apr" release="6.oe2203sp1" version="1.7.0">
                         <filename>apr-1.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1120</id>
          <title>An update for git is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22490" id="CVE-2023-22490" title="CVE-2023-22490" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23946" id="CVE-2023-23946" title="CVE-2023-23946" type="cve"></reference>
          </references>
          <description>Git is a revision control system. Using a specially-crafted repository, Git prior to versions 2.39.2, 2.38.4, 2.37.6, 2.36.5, 2.35.7, 2.34.7, 2.33.7, 2.32.6, 2.31.7, and 2.30.8 can be tricked into using its local clone optimization even when using a non-local transport. Though Git will abort local clones whose source `$GIT_DIR/objects` directory contains symbolic links, the `objects` directory itself may still be a symbolic link. These two may be combined to include arbitrary files based on known paths on the victim&#39;s filesystem within the malicious repository&#39;s working copy, allowing for data exfiltration in a similar manner as CVE-2022-39253. A fix has been prepared and will appear in v2.39.2 v2.38.4 v2.37.6 v2.36.5 v2.35.7 v2.34.7 v2.33.7 v2.32.6, v2.31.7 and v2.30.8. If upgrading is impractical, two short-term workarounds are available. Avoid cloning repositories from untrusted sources with `--recurse-submodules`. Instead, consider cloning repositories without recursively cloning their submodules, and instead run `git submodule update` at each layer. Before doing so, inspect each new `.gitmodules` file to ensure that it does not contain suspicious module URLs.(CVE-2023-22490)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-2023-23946)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="git-debuginfo" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-daemon" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-core" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debugsource" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-help" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-help-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="gitk" release="9.oe2203sp1" version="2.33.0">
                         <filename>gitk-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-gui" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-gui-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git" release="9.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-email" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-email-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-svn" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-svn-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-web" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-web-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git-SVN" release="9.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-SVN-2.33.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-daemon" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-core" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debuginfo" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debugsource" release="9.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1121</id>
          <title>An update for shim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
          </references>
          <description>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-0286)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="shim" release="9.oe2203sp1" version="15.6">
                         <filename>shim-15.6-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debugsource" release="9.oe2203sp1" version="15.6">
                         <filename>shim-debugsource-15.6-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debuginfo" release="9.oe2203sp1" version="15.6">
                         <filename>shim-debuginfo-15.6-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="shim" release="9.oe2203sp1" version="15.6">
                         <filename>shim-15.6-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1125</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23915" id="CVE-2023-23915" title="CVE-2023-23915" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23914" id="CVE-2023-23914" title="CVE-2023-23914" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23916" id="CVE-2023-23916" title="CVE-2023-23916" type="cve"></reference>
          </references>
          <description>A flaw was found in the Curl package, where the HSTS mechanism could fail when multiple transfers are done in parallel, as the HSTS cache file gets overwritten by the most recently completed transfer. This issue may result in limited confidentiality and integrity.(CVE-2023-23915)A flaw was found in the Curl package, where the HSTS mechanism would be ignored by subsequent transfers when done on the same command line because the state would not be properly carried. This issue may result in limited confidentiality and integrity.(CVE-2023-23914)curl supports &#34;chained&#34; HTTP compression algorithms, meaning that a server response can be compressed multiple times and potentially with different algorithms. The number of acceptable &#34;links&#34; in this &#34;decompression chain&#34; was capped, but the cap was implemented on a per-header basis allowing a malicious server to insert a virtually unlimited number of compression steps simply by using many headers. The use of such a decompression chain could result in a &#34;malloc bomb&#34;, making curl end up spending enormous amounts of allocated heap memory, or trying to and returning out of memory errors.(CVE-2023-23916)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="curl" release="14.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl" release="14.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="14.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="14.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl-devel" release="14.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="14.oe2203sp1" version="7.79.1">
                         <filename>curl-help-7.79.1-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="14.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="14.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="14.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="14.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="14.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1126</id>
          <title>An update for gnutls is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0361" id="CVE-2023-0361" title="CVE-2023-0361" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-0361)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnutls" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-utils" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debugsource" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-devel" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debuginfo" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnutls-help" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-help-3.7.2-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-utils" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debuginfo" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debugsource" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-devel" release="7.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1127</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0494" id="CVE-2023-0494" title="CVE-2023-0494" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-0494)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="16.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1128</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0801" id="CVE-2023-0801" title="CVE-2023-0801" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0797" id="CVE-2023-0797" title="CVE-2023-0797" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0796" id="CVE-2023-0796" title="CVE-2023-0796" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0799" id="CVE-2023-0799" title="CVE-2023-0799" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0804" id="CVE-2023-0804" title="CVE-2023-0804" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0802" id="CVE-2023-0802" title="CVE-2023-0802" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0795" id="CVE-2023-0795" title="CVE-2023-0795" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0803" id="CVE-2023-0803" title="CVE-2023-0803" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0800" id="CVE-2023-0800" title="CVE-2023-0800" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0798" id="CVE-2023-0798" title="CVE-2023-0798" type="cve"></reference>
          </references>
          <description>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-0801)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-0797)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-0796)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-0799)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.(CVE-2023-0804)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-0802)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-0795)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-0803)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-0800)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-0798)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-tools" release="23.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="23.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="23.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="23.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="23.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="23.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="23.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="24.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1129</id>
          <title>An update for less is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-02-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46663" id="CVE-2022-46663" title="CVE-2022-46663" type="cve"></reference>
          </references>
          <description>In GNU Less before 609, crafted data can result in &#34;less -R&#34; not filtering ANSI escape sequences sent to the terminal.(CVE-2022-46663)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="less" release="4.oe2203sp1" version="590">
                         <filename>less-590-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="less-debuginfo" release="4.oe2203sp1" version="590">
                         <filename>less-debuginfo-590-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="less-debugsource" release="4.oe2203sp1" version="590">
                         <filename>less-debugsource-590-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="less-help" release="4.oe2203sp1" version="590">
                         <filename>less-help-590-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less-debuginfo" release="4.oe2203sp1" version="590">
                         <filename>less-debuginfo-590-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less" release="4.oe2203sp1" version="590">
                         <filename>less-590-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less-debugsource" release="4.oe2203sp1" version="590">
                         <filename>less-debugsource-590-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1131</id>
          <title>An update for glibc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0687" id="CVE-2023-0687" title="CVE-2023-0687" type="cve"></reference>
          </references>
          <description>** DISPUTED ** A vulnerability was found in GNU C Library 2.38. It has been declared as critical. This vulnerability affects the function __monstartup of the file gmon.c of the component Call Graph Monitor. The manipulation leads to buffer overflow. It is recommended to apply a patch to fix this issue. VDB-220246 is the identifier assigned to this vulnerability. NOTE: The real existence of this vulnerability is still doubted at the moment. The inputs that induce this vulnerability are basically addresses of the running application that is built with gmon enabled. It&#39;s basically trusted input or input that needs an actual security flaw to be compromised or controlled.(CVE-2023-0687)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nss_modules" release="112.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-nss-devel" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-devel" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-archive" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debuginfo" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-all-langpacks" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnsl" release="112.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-common" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-compat-2.17" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugutils" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugsource" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-source" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nscd" release="112.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glibc-help" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-help-2.34-112.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nscd" release="112.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debuginfo" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-nss-devel" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-archive" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-devel" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnsl" release="112.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugsource" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-common" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-source" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugutils" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss_modules" release="112.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-compat-2.17" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-all-langpacks" release="112.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-112.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1133</id>
          <title>An update for rubygem-activerecord is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44566" id="CVE-2022-44566" title="CVE-2022-44566" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22794" id="CVE-2023-22794" title="CVE-2023-22794" type="cve"></reference>
          </references>
          <description>A denial of service vulnerability present in ActiveRecord&#39;s PostgreSQL adapter &lt;7.0.4.1 and &lt;6.1.7.1. When a value outside the range for a 64bit signed integer is provided to the PostgreSQL connection adapter, it will treat the target column type as numeric. Comparing integer values against numeric values can result in a slow sequential scan resulting in potential Denial of Service.(CVE-2022-44566)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.(CVE-2023-22794)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-activerecord-doc" release="2.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activerecord-doc-6.1.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-activerecord" release="2.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activerecord-6.1.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1134</id>
          <title>An update for leptonica is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-04"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38266" id="CVE-2022-38266" title="CVE-2022-38266" type="cve"></reference>
          </references>
          <description>An issue in the Leptonica linked library (v1.79.0) allows attackers to cause an arithmetic exception leading to a Denial of Service (DoS) via a crafted JPEG file.(CVE-2022-38266)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="leptonica-tools" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-tools-1.79.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="leptonica-devel" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-devel-1.79.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="leptonica-debuginfo" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-debuginfo-1.79.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="leptonica" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-1.79.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="leptonica-debugsource" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-debugsource-1.79.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="leptonica-debugsource" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-debugsource-1.79.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="leptonica" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-1.79.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="leptonica-debuginfo" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-debuginfo-1.79.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="leptonica-tools" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-tools-1.79.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="leptonica-devel" release="3.oe2203sp1" version="1.79.0">
                         <filename>leptonica-devel-1.79.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1135</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-04"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0401" id="CVE-2023-0401" title="CVE-2023-0401" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"></reference>
          </references>
          <description>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-0215)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-0286)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.(CVE-2023-0401)The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &#34;name&#34; (e.g. &#34;CERTIFICATE&#34;), any header data and the payload data. If the function succeeds then the &#34;name_out&#34;, &#34;header&#34; and &#34;data&#34; arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. These locations include the PEM_read_bio_TYPE() functions as well as the decoders introduced in OpenSSL 3.0. The OpenSSL asn1parse command line application is also impacted by this issue.(CVE-2022-4450)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="11.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="11.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="11.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="11.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="11.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="11.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="11.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="11.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="11.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="11.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1136</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-04"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24580" id="CVE-2023-24580" title="CVE-2023-24580" type="cve"></reference>
          </references>
          <description>An issue was discovered in the Multipart Request Parser in Django 3.2 before 3.2.18, 4.0 before 4.0.10, and 4.1 before 4.1.7. Passing certain inputs (e.g., an excessive number of parts) to multipart forms could result in too many open files or memory exhaustion, and provided a potential vector for a denial-of-service attack.(CVE-2023-24580)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="3.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="3.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1138</id>
          <title>An update for mujs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-04"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44789" id="CVE-2022-44789" title="CVE-2022-44789" type="cve"></reference>
          </references>
          <description>A logical issue in O_getOwnPropertyDescriptor() in Artifex MuJS 1.0.0 through 1.3.x before 1.3.2 allows an attacker to achieve Remote Code Execution through memory corruption, via the loading of a crafted JavaScript file.(CVE-2022-44789)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mujs" release="3.oe2203sp1" version="1.2.0">
                         <filename>mujs-1.2.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mujs-debuginfo" release="3.oe2203sp1" version="1.2.0">
                         <filename>mujs-debuginfo-1.2.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mujs-debugsource" release="3.oe2203sp1" version="1.2.0">
                         <filename>mujs-debugsource-1.2.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mujs-devel" release="3.oe2203sp1" version="1.2.0">
                         <filename>mujs-devel-1.2.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mujs" release="3.oe2203sp1" version="1.2.0">
                         <filename>mujs-1.2.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mujs-devel" release="3.oe2203sp1" version="1.2.0">
                         <filename>mujs-devel-1.2.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mujs-debuginfo" release="3.oe2203sp1" version="1.2.0">
                         <filename>mujs-debuginfo-1.2.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mujs-debugsource" release="3.oe2203sp1" version="1.2.0">
                         <filename>mujs-debugsource-1.2.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1141</id>
          <title>An update for haproxy is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-04"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0056" id="CVE-2023-0056" title="CVE-2023-0056" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25725" id="CVE-2023-25725" title="CVE-2023-25725" type="cve"></reference>
          </references>
          <description>Initial description: Router PODs frequently getting restarted and haproxy process is receiving the segfault but it is not generating coredump even though the core file size is unlimited.Upstream bug: https://github.com/haproxy/haproxy/issues/1972(CVE-2023-0056)HAProxy before 2.7.3 may allow a bypass of access control because HTTP/1 headers are inadvertently lost in some situations, aka &#34;request smuggling.&#34; The HTTP header parsers in HAProxy may accept empty header field names, which could be used to truncate the list of HTTP headers and thus make some headers disappear after being parsed and processed for HTTP/1.0 and HTTP/1.1. For HTTP/2 and HTTP/3, the impact is limited because the headers disappear before being parsed and processed, as if they had not been sent by the client. The fixed versions are 2.7.3, 2.6.9, 2.5.12, 2.4.22, 2.2.29, and 2.0.31.(CVE-2023-25725)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="haproxy-debugsource" release="2.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy" release="2.oe2203sp1" version="2.6.6">
                         <filename>haproxy-2.6.6-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debuginfo" release="2.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="haproxy-help" release="2.oe2203sp1" version="2.6.6">
                         <filename>haproxy-help-2.6.6-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debuginfo" release="2.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy" release="2.oe2203sp1" version="2.6.6">
                         <filename>haproxy-2.6.6-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debugsource" release="2.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1142</id>
          <title>An update for nodejs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-04"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0286" id="CVE-2023-0286" title="CVE-2023-0286" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4450" id="CVE-2022-4450" title="CVE-2022-4450" type="cve"></reference>
          </references>
          <description>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-0215)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-0286)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-4304)The function PEM_read_bio_ex() reads a PEM file from a BIO and parses and decodes the &#34;name&#34; (e.g. &#34;CERTIFICATE&#34;), any header data and the payload data. If the function succeeds then the &#34;name_out&#34;, &#34;header&#34; and &#34;data&#34; arguments are populated with pointers to buffers containing the relevant decoded data. The caller is responsible for freeing those buffers. It is possible to construct a PEM file that results in 0 bytes of payload data. In this case PEM_read_bio_ex() will return a failure code but will populate the header argument with a pointer to a buffer that has already been freed. If the caller also frees this buffer then a double free will occur. This will most likely lead to a crash. This could be exploited by an attacker who has the ability to supply malicious PEM files for parsing to achieve a denial of service attack. The functions PEM_read_bio() and PEM_read() are simple wrappers around PEM_read_bio_ex() and therefore these functions are also directly affected. These functions are also called indirectly by a number of other OpenSSL functions including PEM_X509_INFO_read_bio_ex() and SSL_CTX_use_serverinfo_file() which are also vulnerable. Some OpenSSL internal uses of these functions are not vulnerable because the caller does not free the header argument if PEM_read_bio_ex() returns a failure code. These locations include the PEM_read_bio_TYPE() functions as well as the decoders introduced in OpenSSL 3.0. The OpenSSL asn1parse command line application is also impacted by this issue.(CVE-2022-4450)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="nodejs-devel" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="npm" release="1.12.22.11.4.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="v8-devel" release="1.12.22.11.4.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debuginfo" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-full-i18n" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debugsource" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-libs" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nodejs-docs" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-docs-12.22.11-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debugsource" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-libs" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-full-i18n" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-devel" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="npm" release="1.12.22.11.4.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="v8-devel" release="1.12.22.11.4.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debuginfo" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs" release="4.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1147</id>
          <title>An update for containerd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-04"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25153" id="CVE-2023-25153" title="CVE-2023-25153" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25173" id="CVE-2023-25173" title="CVE-2023-25173" type="cve"></reference>
          </references>
          <description>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-25153)containerd is an open source container runtime. A bug was found in containerd prior to versions 1.6.18 and 1.5.18 where supplementary groups are not set up properly inside a container. If an attacker has direct access to a container and manipulates their supplementary group access, they may be able to use supplementary group access to bypass primary group restrictions in some cases, potentially gaining access to sensitive information or gaining the ability to execute code in that container. Downstream applications that use the containerd client library may be affected as well. This bug has been fixed in containerd v1.6.18 and v.1.5.18. Users should update to these versions and recreate containers to resolve this issue. Users who rely on a downstream application that uses containerd&#39;s client library should check that application for a separate advisory and instructions. As a workaround, ensure that the `&#34;USER $USERNAME&#34;` Dockerfile instruction is not used. Instead, set the container entrypoint to a value similar to `ENTRYPOINT [&#34;su&#34;, &#34;-&#34;, &#34;user&#34;]` to allow `su` to properly set up supplementary groups.(CVE-2023-25173)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="containerd" release="309.oe2203sp1" version="1.2.0">
                         <filename>containerd-1.2.0-309.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="containerd" release="309.oe2203sp1" version="1.2.0">
                         <filename>containerd-1.2.0-309.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1148</id>
          <title>An update for emacs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-04"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48339" id="CVE-2022-48339" title="CVE-2022-48339" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48338" id="CVE-2022-48338" title="CVE-2022-48338" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48337" id="CVE-2022-48337" title="CVE-2022-48337" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-48339)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.(CVE-2022-48338)GNU Emacs through 28.2 allows attackers to execute commands via shell metacharacters in the name of a source-code file, because lib-src/etags.c uses the system C library function in its implementation of the etags program. For example, a victim may use the &#34;etags -u *&#34; command (suggested in the etags documentation) in a situation where the current working directory has contents that depend on untrusted input.(CVE-2022-48337)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="emacs-devel" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-devel-27.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-lucid" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-lucid-27.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debuginfo" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-debuginfo-27.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-common" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-common-27.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debugsource" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-debugsource-27.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-27.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-nox" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-nox-27.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-terminal" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-terminal-27.2-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-filesystem" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-filesystem-27.2-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-help" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-help-27.2-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-common" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-common-27.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debugsource" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-debugsource-27.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-devel" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-devel-27.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-lucid" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-lucid-27.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-27.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debuginfo" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-debuginfo-27.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-nox" release="9.oe2203sp1" version="27.2">
                         <filename>emacs-nox-27.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1149</id>
          <title>An update for amanda is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37705" id="CVE-2022-37705" title="CVE-2022-37705" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37704" id="CVE-2022-37704" title="CVE-2022-37704" type="cve"></reference>
          </references>
          <description>A flaw was found in Amanda. The `runtar` SUID binary executes /usr/bin/tar as root without properly validating its arguments, possibly leading to escalation of privileges from the regular user &#34;amandabackup&#34; to root.(CVE-2022-37705)A flaw was found in Amanda. The `rundump` SUID binary executes /usr/sbin/dump as root without properly validating its arguments, possibly leading to escalation of privileges from the regular user &#34;amandabackup&#34; to root.(CVE-2022-37704)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="amanda-debugsource" release="23.oe2203sp1" version="3.5.1">
                         <filename>amanda-debugsource-3.5.1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="amanda-debuginfo" release="23.oe2203sp1" version="3.5.1">
                         <filename>amanda-debuginfo-3.5.1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="amanda" release="23.oe2203sp1" version="3.5.1">
                         <filename>amanda-3.5.1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="amanda-help" release="23.oe2203sp1" version="3.5.1">
                         <filename>amanda-help-3.5.1-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="amanda-debugsource" release="23.oe2203sp1" version="3.5.1">
                         <filename>amanda-debugsource-3.5.1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="amanda" release="23.oe2203sp1" version="3.5.1">
                         <filename>amanda-3.5.1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="amanda-debuginfo" release="23.oe2203sp1" version="3.5.1">
                         <filename>amanda-debuginfo-3.5.1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1151</id>
          <title>An update for libreswan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23009" id="CVE-2023-23009" title="CVE-2023-23009" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-23009)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libreswan" release="3.oe2203sp1" version="4.5">
                         <filename>libreswan-4.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-help" release="3.oe2203sp1" version="4.5">
                         <filename>libreswan-help-4.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debuginfo" release="3.oe2203sp1" version="4.5">
                         <filename>libreswan-debuginfo-4.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debugsource" release="3.oe2203sp1" version="4.5">
                         <filename>libreswan-debugsource-4.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan" release="3.oe2203sp1" version="4.5">
                         <filename>libreswan-4.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-help" release="3.oe2203sp1" version="4.5">
                         <filename>libreswan-help-4.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debuginfo" release="3.oe2203sp1" version="4.5">
                         <filename>libreswan-debuginfo-4.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debugsource" release="3.oe2203sp1" version="4.5">
                         <filename>libreswan-debugsource-4.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1154</id>
          <title>An update for rubygem-activesupport is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22796" id="CVE-2023-22796" title="CVE-2023-22796" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-22796)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport" release="3.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activesupport-6.1.4.1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport-doc" release="3.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activesupport-doc-6.1.4.1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1155</id>
          <title>An update for apache-commons-fileupload is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24998" id="CVE-2023-24998" title="CVE-2023-24998" type="cve"></reference>
          </references>
          <description>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-24998)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="apache-commons-fileupload" release="2.oe2203sp1" version="1.4">
                         <filename>apache-commons-fileupload-1.4-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="apache-commons-fileupload-help" release="2.oe2203sp1" version="1.4">
                         <filename>apache-commons-fileupload-help-1.4-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1157</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0240" id="CVE-2023-0240" title="CVE-2023-0240" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0615" id="CVE-2023-0615" title="CVE-2023-0615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0045" id="CVE-2023-0045" title="CVE-2023-0045" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23586" id="CVE-2023-23586" title="CVE-2023-23586" type="cve"></reference>
          </references>
          <description>There is a logic error in io_uring&#39;s implementation which can be used to trigger a use-after-free vulnerability leading to privilege escalation. In the io_prep_async_work function the assumption that the last io_grab_identity call cannot return false is not true, and in this case the function will use the init_cred or the previous linked requests identity to do operations instead of using the current identity. This can lead to reference counting issues causing use-after-free. We recommend upgrading past version 5.10.161.(CVE-2023-0240)A memory leak flaw and potential divide by zero and Integer overflow was found in the Linux kernel V4L2 and vivid test code functionality. This issue occurs when a user triggers ioctls, such as VIDIOC_S_DV_TIMINGS ioctl. This could allow a local user to crash the system if vivid test code enabled.(CVE-2023-0615)The Linux kernel does not correctly mitigate SMT attacks, as discoveredthrough a strange pattern in the kernel API using STIBP as a mitigation[1&lt;https://docs.kernel.org/userspace-api/spec_ctrl.html&gt;], leaving theprocess exposed for a short period of time after a syscall. The kernel alsodoes not issue an IBPB immediately during the syscall.The ib_prctl_set [2&lt;https://elixir.bootlin.com/linux/v5.15.56/source/arch/x86/kernel/cpu/bugs.c#L1467&gt;]functionupdates the Thread Information Flags (TIFs) for the task and updates theSPEC_CTRL MSR on the function __speculation_ctrl_update [3&lt;https://elixir.bootlin.com/linux/v5.15.56/source/arch/x86/kernel/process.c#L557&gt;],but the IBPB is only issued on the next schedule, when the TIF bits arechecked. This leaves the victim vulnerable to values already injected onthe BTB, prior to the prctl syscall.The behavior is only corrected after a reschedule of the task happens.Furthermore, the kernel entrance (due to the syscall itself), does notissue an IBPB in the default scenarios (i.e., when the kernel protectsitself via retpoline or eIBRS).(CVE-2023-0045)Due to a vulnerability in the io_uring subsystem, it is possible to leak kernel memory information to the user process. timens_install calls current_is_single_threaded to determine if the current process is single-threaded, but this call does not consider io_uring&#39;s io_worker threads, thus it is possible to insert a time namespace&#39;s vvar page to process&#39;s memory space via a page fault. When this time namespace is destroyed, the vvar page is also freed, but not removed from the process&#39; memory, and a next page allocated by the kernel will be still available from the user-space process and can leak memory contents via this (read-only) use-after-free vulnerability. We recommend upgrading past version 5.10.161 or commit 788d0824269bef539fe31a785b1517882eafed93 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/io_uring(CVE-2023-23586)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.21.0.97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.21.0.97.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.21.0.97.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1158</id>
          <title>An update for libksba is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47629" id="CVE-2022-47629" title="CVE-2022-47629" type="cve"></reference>
          </references>
          <description>Libksba before 1.6.3 is prone to an integer overflow vulnerability in the CRL signature parser.(CVE-2022-47629)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libksba" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-1.6.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libksba-debuginfo" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-debuginfo-1.6.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libksba-devel" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-devel-1.6.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libksba-debugsource" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-debugsource-1.6.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libksba-help" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-help-1.6.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libksba-debugsource" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-debugsource-1.6.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libksba" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-1.6.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libksba-debuginfo" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-debuginfo-1.6.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libksba-devel" release="3.oe2203sp1" version="1.6.0">
                         <filename>libksba-devel-1.6.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1159</id>
          <title>An update for pesign is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3560" id="CVE-2022-3560" title="CVE-2022-3560" type="cve"></reference>
          </references>
          <description>A flaw was found in pesign. The pesign package provides a systemd service used to start the pesign daemon. This service unit runs a script to set ACLs for /etc/pki/pesign and /run/pesign directories to grant access privileges to users in the &#39;pesign&#39; group. However, the script doesn&#39;t check for symbolic links. This could allow an attacker to gain access to privileged files and directories via a path traversal attack.(CVE-2022-3560)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pesign-debugsource" release="4.oe2203sp1" version="115">
                         <filename>pesign-debugsource-115-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pesign-help" release="4.oe2203sp1" version="115">
                         <filename>pesign-help-115-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pesign" release="4.oe2203sp1" version="115">
                         <filename>pesign-115-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pesign-debuginfo" release="4.oe2203sp1" version="115">
                         <filename>pesign-debuginfo-115-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pesign-debuginfo" release="4.oe2203sp1" version="115">
                         <filename>pesign-debuginfo-115-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pesign-debugsource" release="4.oe2203sp1" version="115">
                         <filename>pesign-debugsource-115-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pesign" release="4.oe2203sp1" version="115">
                         <filename>pesign-115-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pesign-help" release="4.oe2203sp1" version="115">
                         <filename>pesign-help-115-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1160</id>
          <title>An update for sudo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27320" id="CVE-2023-27320" title="CVE-2023-27320" type="cve"></reference>
          </references>
          <description>Sudo before 1.9.13p2 has a double free in the per-command chroot feature.(CVE-2023-27320)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sudo-devel" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-devel-1.9.8p2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-debuginfo" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debuginfo-1.9.8p2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-debugsource" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debugsource-1.9.8p2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-1.9.8p2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sudo-help" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-help-1.9.8p2-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-debugsource" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debugsource-1.9.8p2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-debuginfo" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debuginfo-1.9.8p2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-devel" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-devel-1.9.8p2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo" release="10.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-1.9.8p2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1161</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27522" id="CVE-2023-27522" title="CVE-2023-27522" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25690" id="CVE-2023-25690" title="CVE-2023-25690" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-27522)Some mod_proxy configurations on Apache HTTP Server versions 2.4.0 through 2.4.55 allow a HTTP Request Smuggling attack. Configurations are affected when mod_proxy is enabled along with some form of RewriteRule or ProxyPassMatch in which a non-specific pattern matches some portion of the user-supplied request-target (URL) data and is then re-inserted into the proxied request-target using variable substitution. For example, something like: RewriteEngine on RewriteRule &#34;^/here/(.*)&#34; &#34;http://example.com:8080/elsewhere?$1&#34;; [P] ProxyPassReverse /here/ http://example.com:8080/ Request splitting/smuggling could result in bypass of access controls in the proxy server, proxying unintended URLs to existing origin servers, and cache poisoning. Users are recommended to update to at least version 2.4.56 of Apache HTTP Server.(CVE-2023-25690)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-help-2.4.51-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="15.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="15.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1163</id>
          <title>An update for snakeyaml is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25857" id="CVE-2022-25857" title="CVE-2022-25857" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38749" id="CVE-2022-38749" title="CVE-2022-38749" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38750" id="CVE-2022-38750" title="CVE-2022-38750" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38751" id="CVE-2022-38751" title="CVE-2022-38751" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38752" id="CVE-2022-38752" title="CVE-2022-38752" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41854" id="CVE-2022-41854" title="CVE-2022-41854" type="cve"></reference>
          </references>
          <description>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-25857)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-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 stack-overflow.(CVE-2022-38752)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.(CVE-2022-41854)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="snakeyaml" release="1.oe2203sp1" version="1.32">
                         <filename>snakeyaml-1.32-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="snakeyaml-javadoc" release="1.oe2203sp1" version="1.32">
                         <filename>snakeyaml-javadoc-1.32-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1168</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1170" id="CVE-2023-1170" title="CVE-2023-1170" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1175" id="CVE-2023-1175" title="CVE-2023-1175" type="cve"></reference>
          </references>
          <description>Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1376.(CVE-2023-1170)Incorrect Calculation of Buffer Size in GitHub repository vim/vim prior to 9.0.1378.(CVE-2023-1175)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-common" release="11.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="11.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="11.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="11.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="11.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="11.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="11.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="11.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="11.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="11.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="11.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="11.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="11.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1169</id>
          <title>An update for clamav is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20032" id="CVE-2023-20032" title="CVE-2023-20032" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20052" id="CVE-2023-20052" title="CVE-2023-20052" type="cve"></reference>
          </references>
          <description>On Feb 15, 2023, the following vulnerability in the ClamAV scanning library was disclosed: A vulnerability in the HFS+ partition file parser of ClamAV versions 1.0.0 and earlier, 0.105.1 and earlier, and 0.103.7 and earlier could allow an unauthenticated, remote attacker to execute arbitrary code. This vulnerability is due to a missing buffer size check that may result in a heap buffer overflow write. An attacker could exploit this vulnerability by submitting a crafted HFS+ partition file to be scanned by ClamAV on an affected device. A successful exploit could allow the attacker to execute arbitrary code with the privileges of the ClamAV scanning process, or else crash the process, resulting in a denial of service (DoS) condition. For a description of this vulnerability, see the ClamAV blog [&#34;https://blog.clamav.net/&#34;].(CVE-2023-20032)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.(CVE-2023-20052)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="clamav-devel" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-devel-0.103.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-update" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-update-0.103.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-debuginfo" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-debuginfo-0.103.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-debugsource" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-debugsource-0.103.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-help" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-help-0.103.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-0.103.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamd" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamd-0.103.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-milter" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-milter-0.103.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-filesystem" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-filesystem-0.103.8-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-data" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-data-0.103.8-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-devel" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-devel-0.103.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-help" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-help-0.103.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-debuginfo" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-debuginfo-0.103.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-milter" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-milter-0.103.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-0.103.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-update" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-update-0.103.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-debugsource" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamav-debugsource-0.103.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamd" release="1.oe2203sp1" version="0.103.8">
                         <filename>clamd-0.103.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1170</id>
          <title>An update for glusterfs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26253" id="CVE-2023-26253" title="CVE-2023-26253" type="cve"></reference>
          </references>
          <description>In Gluster GlusterFS 11.0, there is an xlators/mount/fuse/src/fuse-bridge.c notify stack-based buffer over-read.(CVE-2023-26253)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libgfxdr-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libgfxdr-devel-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-geo-replication" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-geo-replication-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-debugsource" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-debugsource-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-fuse" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-fuse-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libglusterd0" release="8.oe2203sp1" version="10.0">
                         <filename>libglusterd0-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfapi0" release="8.oe2203sp1" version="10.0">
                         <filename>libgfapi0-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libglusterfs0" release="8.oe2203sp1" version="10.0">
                         <filename>libglusterfs0-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-events" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-events-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-cloudsync-plugins" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-cloudsync-plugins-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfxdr0" release="8.oe2203sp1" version="10.0">
                         <filename>libgfxdr0-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-gluster" release="8.oe2203sp1" version="10.0">
                         <filename>python3-gluster-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-extra-xlators" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-extra-xlators-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-server" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-server-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfrpc-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libgfrpc-devel-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-client-xlators" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-client-xlators-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfrpc0" release="8.oe2203sp1" version="10.0">
                         <filename>libgfrpc0-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libglusterfs-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libglusterfs-devel-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-debuginfo" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-debuginfo-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-help" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-help-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-cli" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-cli-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-thin-arbiter" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-thin-arbiter-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfapi-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libgfapi-devel-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfchangelog-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libgfchangelog-devel-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfchangelog0" release="8.oe2203sp1" version="10.0">
                         <filename>libgfchangelog0-10.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glusterfs-resource-agents" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-resource-agents-10.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libglusterfs-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libglusterfs-devel-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfchangelog0" release="8.oe2203sp1" version="10.0">
                         <filename>libgfchangelog0-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-cli" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-cli-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-debuginfo" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-debuginfo-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-extra-xlators" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-extra-xlators-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-server" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-server-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-client-xlators" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-client-xlators-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfrpc-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libgfrpc-devel-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-geo-replication" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-geo-replication-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfxdr-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libgfxdr-devel-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libglusterd0" release="8.oe2203sp1" version="10.0">
                         <filename>libglusterd0-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfchangelog-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libgfchangelog-devel-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-fuse" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-fuse-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-thin-arbiter" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-thin-arbiter-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfapi-devel" release="8.oe2203sp1" version="10.0">
                         <filename>libgfapi-devel-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-gluster" release="8.oe2203sp1" version="10.0">
                         <filename>python3-gluster-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-debugsource" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-debugsource-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-help" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-help-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfrpc0" release="8.oe2203sp1" version="10.0">
                         <filename>libgfrpc0-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libglusterfs0" release="8.oe2203sp1" version="10.0">
                         <filename>libglusterfs0-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfxdr0" release="8.oe2203sp1" version="10.0">
                         <filename>libgfxdr0-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfapi0" release="8.oe2203sp1" version="10.0">
                         <filename>libgfapi0-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-cloudsync-plugins" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-cloudsync-plugins-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-events" release="8.oe2203sp1" version="10.0">
                         <filename>glusterfs-events-10.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1171</id>
          <title>An update for libmicrohttpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27371" id="CVE-2023-27371" title="CVE-2023-27371" type="cve"></reference>
          </references>
          <description>GNU libmicrohttpd before 0.9.76 allows remote DoS (Denial of Service) due to improper parsing of a multipart/form-data boundary in the postprocessor.c MHD_create_post_processor() method. This allows an attacker to remotely send a malicious HTTP POST packet that includes one or more &#39;\0&#39; bytes in a multipart/form-data boundary field, which - assuming a specific heap layout - will result in an out-of-bounds read and a crash in the find_boundary() function.(CVE-2023-27371)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="libmicrohttpd-debuginfo" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-debuginfo-0.9.75-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libmicrohttpd-debugsource" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-debugsource-0.9.75-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libmicrohttpd-devel" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-devel-0.9.75-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libmicrohttpd" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-0.9.75-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="libmicrohttpd-help" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-help-0.9.75-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libmicrohttpd-debugsource" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-debugsource-0.9.75-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libmicrohttpd-debuginfo" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-debuginfo-0.9.75-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libmicrohttpd-devel" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-devel-0.9.75-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libmicrohttpd" release="4.oe2203sp1" version="0.9.75">
                         <filename>libmicrohttpd-0.9.75-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1175</id>
          <title>An update for epiphany is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26081" id="CVE-2023-26081" title="CVE-2023-26081" type="cve"></reference>
          </references>
          <description>In Epiphany (aka GNOME Web) through 43.0, untrusted web content can trick users into exfiltrating passwords, because autofill occurs in sandboxed contexts.(CVE-2023-26081)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="epiphany" release="3.oe2203sp1" version="40.6">
                         <filename>epiphany-40.6-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="epiphany-runtime" release="3.oe2203sp1" version="40.6">
                         <filename>epiphany-runtime-40.6-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="epiphany-debugsource" release="3.oe2203sp1" version="40.6">
                         <filename>epiphany-debugsource-40.6-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="epiphany-debuginfo" release="3.oe2203sp1" version="40.6">
                         <filename>epiphany-debuginfo-40.6-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="epiphany-runtime" release="3.oe2203sp1" version="40.6">
                         <filename>epiphany-runtime-40.6-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="epiphany-debuginfo" release="3.oe2203sp1" version="40.6">
                         <filename>epiphany-debuginfo-40.6-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="epiphany-debugsource" release="3.oe2203sp1" version="40.6">
                         <filename>epiphany-debugsource-40.6-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="epiphany" release="3.oe2203sp1" version="40.6">
                         <filename>epiphany-40.6-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1176</id>
          <title>An update for future is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40899" id="CVE-2022-40899" title="CVE-2022-40899" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-40899)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-future" release="2.oe2203sp1" version="0.18.2">
                         <filename>python3-future-0.18.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1178</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20938" id="CVE-2023-20938" title="CVE-2023-20938" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0461" id="CVE-2023-0461" title="CVE-2023-0461" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26607" id="CVE-2023-26607" title="CVE-2023-26607" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1075" id="CVE-2023-1075" title="CVE-2023-1075" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1078" id="CVE-2023-1078" title="CVE-2023-1078" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1076" id="CVE-2023-1076" title="CVE-2023-1076" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22995" id="CVE-2023-22995" title="CVE-2023-22995" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1118" id="CVE-2023-1118" title="CVE-2023-1118" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26545" id="CVE-2023-26545" title="CVE-2023-26545" type="cve"></reference>
          </references>
          <description>In binder_transaction_buffer_release of binder.c, there is a possible use after free due to improper input validation. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.Product: AndroidVersions: Android kernelAndroid ID: A-257685302References: Upstream kernel(CVE-2023-20938)There is a use-after-free vulnerability in the Linux Kernel which can be exploited to achieve local privilege escalation. To reach the vulnerability kernel configuration flag CONFIG_TLS or CONFIG_XFRM_ESPINTCP has to be configured, but the operation does not require any privilege. There is a use-after-free bug of icsk_ulp_data of a struct inet_connection_sock. When CONFIG_TLS is enabled, user can install a tls context (struct tls_context) on a connected tcp socket. The context is not cleared if this socket is disconnected and reused as a listener. If a new socket is created from the listener, the context is inherited and vulnerable. The setsockopt TCP_ULP operation does not require any privilege. We recommend upgrading past commit 2c02d41d71f90a5168391b6a5f2954112ba2307c(CVE-2023-0461)In the Linux kernel 6.0.8, there is an out-of-bounds read in ntfs_attr_find in fs/ntfs/attrib.c.(CVE-2023-26607)A flaw in the Linux Kernel found. The tls_is_tx_ready() incorrectly checks for list emptiness, potentially accessing a type confused entry to the list_head, leaking the last byte of the confused field that overlaps with rec-&gt;tx_ready.Reference:https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=ffe2a22562444720b05bdfeb999c03e810d84cbb(CVE-2023-1075)A flaw found in the Linux Kernel in RDS (Reliable Datagram Sockets) protocol. The rds_rm_zerocopy_callback() uses list_entry() on the head of a list causing a type confusion. Local user can trigger this with rds_message_put(). Type confusion leads to `struct rds_msg_zcopy_info *info` actually points to something else that is potentially controlled by local user.It is known how to trigger this, which causes an OOB access, and a lock corruption.Reference:https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=f753a68980cf4b59a80fe677619da2b1804f526d(CVE-2023-1078)A flaw found in the Linux Kernel. The tun/tap sockets have their socket UID hardcoded to 0 due to a type confusion in their initialization function.While it will be often correct, as tuntap devices require CAP_NET_ADMIN, it may not always be the case, e.g., a non-root user only having that capability.This would make tun/tap sockets being incorrectly treated in filtering/routing decisions, possibly bypassing network filters.References:https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=66b2c338adce580dfce2199591e65e2bab889cffhttps://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=a096ccca6e503a5c575717ff8a36ace27510ab0a(CVE-2023-1076)In the Linux kernel before 5.17, an error path in dwc3_qcom_acpi_register_core in drivers/usb/dwc3/dwc3-qcom.c lacks certain platform_device_put and kfree calls.(CVE-2023-22995)A flaw use after free in the Linux kernel integrated infrared receiver/transceiver driver was found in the way user detaching rc device. A local user could use this flaw to crash the system or potentially escalate their privileges on the system.(CVE-2023-1118)In the Linux kernel before 6.1.13, there is a double free in net/mpls/af_mpls.c upon an allocation failure (for registering the sysctl table under a new location) during the renaming of a device.(CVE-2023-26545)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="perf" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.22.0.98.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.22.0.98.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.22.0.98.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1179</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1264" id="CVE-2023-1264" title="CVE-2023-1264" type="cve"></reference>
          </references>
          <description>NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1392.(CVE-2023-1264)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="12.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="12.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="12.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="12.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="12.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="12.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="12.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="12.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="12.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="12.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="12.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="12.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="12.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1180</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1074" id="CVE-2023-1074" title="CVE-2023-1074" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1079" id="CVE-2023-1079" title="CVE-2023-1079" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1073" id="CVE-2023-1073" title="CVE-2023-1073" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1382" id="CVE-2023-1382" title="CVE-2023-1382" type="cve"></reference>
          </references>
          <description>A flaw in the Linux Kernel found. Fail if no bound addresses can be used for a given scope. A type confusion can happen in inet_diag_msg_sctpasoc_fill() in net/sctp/diag.c, which uses a type confused pointer to return information to userspace when issuing a list_entry() on asoc-&gt;base.bind_addr.address_list.next when the list is empty.References:https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=458e279f861d3f61796894cd158b780765a1569fhttps://www.openwall.com/lists/oss-security/2023/01/23/1(CVE-2023-1074)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.Reference:https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=4ab3a086d10eeec1424f2e8a968827a6336203df(CVE-2023-1079)A flaw found in the Linux Kernel. The missing check causes a type confusion when issuing a list_entry()on an empty report_list. The problem is caused by the assumption that the device must have valid report_list. While this will be true for all normal HID devices, a suitably malicious device can violate the assumption.References:https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=b12fece4c64857e5fab4290bf01b2e0317a88456https://www.openwall.com/lists/oss-security/2023/01/17/3(CVE-2023-1073)Kernel: denial of service in tipc_conn_close(CVE-2023-1382)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-headers" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.24.0.100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.24.0.100.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.24.0.100.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1183</id>
          <title>An update for poppler is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-27337" id="CVE-2022-27337" title="CVE-2022-27337" type="cve"></reference>
          </references>
          <description>A logic error in the Hints::Hints function of Poppler v22.03.0 allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.(CVE-2022-27337)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="poppler-qt5" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-utils" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-utils-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib-devel" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5-devel" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debuginfo" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debugsource" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-devel" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-devel-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp-devel" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-glib-doc" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-doc-0.90.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-help" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-help-0.90.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debuginfo" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-devel" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-devel-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib-devel" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp-devel" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5-devel" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-utils" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-utils-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debugsource" release="4.oe2203sp1" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1184</id>
          <title>An update for redis is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36021" id="CVE-2022-36021" title="CVE-2022-36021" type="cve"></reference>
          </references>
          <description>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. The problem is fixed in Redis versions 6.0.18, 6.2.11, 7.0.9.(CVE-2022-36021)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="redis-debuginfo" release="2.oe2203sp1" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis" release="2.oe2203sp1" version="4.0.14">
                         <filename>redis-4.0.14-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debugsource" release="2.oe2203sp1" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debugsource" release="2.oe2203sp1" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debuginfo" release="2.oe2203sp1" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis" release="2.oe2203sp1" version="4.0.14">
                         <filename>redis-4.0.14-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1185</id>
          <title>An update for emacs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-03-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28617" id="CVE-2023-28617" title="CVE-2023-28617" type="cve"></reference>
          </references>
          <description>org-babel-execute:latex in ob-latex.el in Org Mode through 9.6.1 for GNU Emacs allows attackers to execute arbitrary commands via a file name or directory name that contains shell metacharacters.(CVE-2023-28617)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="emacs" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-27.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-common" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-common-27.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-nox" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-nox-27.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debuginfo" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-debuginfo-27.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debugsource" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-debugsource-27.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-lucid" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-lucid-27.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-devel" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-devel-27.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-terminal" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-terminal-27.2-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-help" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-help-27.2-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-filesystem" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-filesystem-27.2-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debuginfo" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-debuginfo-27.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-nox" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-nox-27.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-27.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-lucid" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-lucid-27.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debugsource" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-debugsource-27.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-common" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-common-27.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-devel" release="10.oe2203sp1" version="27.2">
                         <filename>emacs-devel-27.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1186</id>
          <title>An update for libfastjson is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-12762" id="CVE-2020-12762" title="CVE-2020-12762" type="cve"></reference>
          </references>
          <description>json-c through 0.14 has an integer overflow and out-of-bounds write via a large JSON file, as demonstrated by printbuf_memappend.(CVE-2020-12762)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libfastjson" release="3.oe2203sp1" version="0.99.9">
                         <filename>libfastjson-0.99.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libfastjson-debugsource" release="3.oe2203sp1" version="0.99.9">
                         <filename>libfastjson-debugsource-0.99.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libfastjson-debuginfo" release="3.oe2203sp1" version="0.99.9">
                         <filename>libfastjson-debuginfo-0.99.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libfastjson-devel" release="3.oe2203sp1" version="0.99.9">
                         <filename>libfastjson-devel-0.99.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libfastjson-debuginfo" release="3.oe2203sp1" version="0.99.9">
                         <filename>libfastjson-debuginfo-0.99.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libfastjson" release="3.oe2203sp1" version="0.99.9">
                         <filename>libfastjson-0.99.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libfastjson-debugsource" release="3.oe2203sp1" version="0.99.9">
                         <filename>libfastjson-debugsource-0.99.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libfastjson-devel" release="3.oe2203sp1" version="0.99.9">
                         <filename>libfastjson-devel-0.99.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1190</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1161" id="CVE-2023-1161" title="CVE-2023-1161" type="cve"></reference>
          </references>
          <description>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(CVE-2023-1161)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="2.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1191</id>
          <title>An update for liblouis is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26769" id="CVE-2023-26769" title="CVE-2023-26769" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-26769)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="liblouis-debugsource" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-debugsource-3.7.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblouis-debuginfo" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-debuginfo-3.7.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblouis-devel" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-devel-3.7.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblouis" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-3.7.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblouis-utils" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-utils-3.7.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-louis" release="5.oe2203sp1" version="3.7.0">
                         <filename>python3-louis-3.7.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="liblouis-help" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-help-3.7.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-3.7.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis-debugsource" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-debugsource-3.7.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis-utils" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-utils-3.7.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis-devel" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-devel-3.7.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis-debuginfo" release="5.oe2203sp1" version="3.7.0">
                         <filename>liblouis-debuginfo-3.7.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1192</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-03-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41724" id="CVE-2022-41724" title="CVE-2022-41724" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41725" id="CVE-2022-41725" title="CVE-2022-41725" type="cve"></reference>
          </references>
          <description>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-41723)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-41724)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. ReadForm takes a maxMemory parameter, and is documented as storing &#34;up to maxMemory bytes +10MB (reserved for non-file parts) in memory&#34;. File parts which cannot be stored in memory are stored on disk in temporary files. The unconfigurable 10MB reserved for non-file parts is excessively large and can potentially open a denial of service vector on its own. However, ReadForm did not properly account for all memory consumed by a parsed form, such as map entry overhead, part names, and MIME headers, permitting a maliciously crafted form to consume well over 10MB. In addition, ReadForm contained no limit on the number of disk files created, permitting a relatively small request body to create a large number of disk temporary files. With fix, ReadForm now properly accounts for various forms of memory overhead, and should now stay within its documented limit of 10MB + maxMemory bytes of memory consumption. Users should still be aware that this limit is high and may still be hazardous. In addition, ReadForm now creates at most one on-disk temporary file, combining multiple form parts into a single temporary file. The mime/multipart.File interface type&#39;s documentation states, &#34;If stored on disk, the File&#39;s underlying concrete type will be an *os.File.&#34;. This is no longer the case when a form contains more than one file part, due to this coalescing of parts into a single file. The previous behavior of using distinct files for each form part may be reenabled with the environment variable GODEBUG=multipartfiles=distinct. Users should be aware that multipart.ReadForm and the http.Request methods that call it do not limit the amount of disk consumed by temporary files. Callers can limit the size of form data with http.MaxBytesReader.(CVE-2022-41725)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="15.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="15.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="15.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="15.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1193</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-03-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27535" id="CVE-2023-27535" title="CVE-2023-27535" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27538" id="CVE-2023-27538" title="CVE-2023-27538" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27536" id="CVE-2023-27536" title="CVE-2023-27536" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27533" id="CVE-2023-27533" title="CVE-2023-27533" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27534" id="CVE-2023-27534" title="CVE-2023-27534" type="cve"></reference>
          </references>
          <description>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-27535)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.(CVE-2023-27538)libcurl would reuse a previously created connection even when the GSS delegation (`CURLOPT_GSSAPI_DELEGATION`) option had been changed that could have changed the user&#39;s permissions in a second transfer. libcurl keeps previously used connections in a connection pool for subsequent transfers to reuse if one of them matches the setup. However, this GSS delegation setting was left out from the configuration match checks, making them match too easily, affecting krb5/kerberos/negotiate/GSSAPI transfers.(CVE-2023-27536)curl supports communicating using the TELNET protocol and as a part of this it offers users to pass on user name and &#34;telnet options&#34; for the servernegotiation. Due to lack of proper input scrubbing and without it being the documented functionality, curl would pass on user name and telnet options to the server as provided. This could allow users to pass in carefully crafted content that pass on content or do option negotiation without the application intending to do so. In particular if an application for example allows users to provide the data or parts of the data.(CVE-2023-27533)curl supports SFTP transfers. curl&#39;s SFTP implementation offers a special feature in the path component of URLs: a tilde (`~`) character as the firstpath element in the path to denotes a path relative to the user&#39;s home directory. This is supported because of wording in the [once proposedto-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-27534)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libcurl" release="15.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl" release="15.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="15.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl-devel" release="15.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="15.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="15.oe2203sp1" version="7.79.1">
                         <filename>curl-help-7.79.1-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="15.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="15.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="15.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="15.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="15.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1201</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0266" id="CVE-2023-0266" title="CVE-2023-0266" type="cve"></reference>
          </references>
          <description>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-0266)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-headers" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.26.0.102.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.26.0.102.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.26.0.102.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1202</id>
          <title>An update for undertow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1108" id="CVE-2023-1108" title="CVE-2023-1108" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-1108)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="undertow" release="5.oe2203sp1" version="1.4.0">
                         <filename>undertow-1.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="undertow-javadoc" release="5.oe2203sp1" version="1.4.0">
                         <filename>undertow-javadoc-1.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1204</id>
          <title>An update for runc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25809" id="CVE-2023-25809" title="CVE-2023-25809" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28642" id="CVE-2023-28642" title="CVE-2023-28642" type="cve"></reference>
          </references>
          <description>runc is a CLI tool for spawning and running containers according to the OCI specification. In affected versions it was found that rootless runc makes `/sys/fs/cgroup` writable in following conditons: 1. when runc is executed inside the user namespace, and the `config.json` does not specify the cgroup namespace to be unshared (e.g.., `(docker|podman|nerdctl) run --cgroupns=host`, with Rootless Docker/Podman/nerdctl) or 2. when runc is executed outside the user namespace, and `/sys` is mounted with `rbind, ro` (e.g., `runc spec --rootless`; this condition is very rare). A container may gain the write access to user-owned cgroup hierarchy `/sys/fs/cgroup/user.slice/...` on the host . Other users&#39;s cgroup hierarchies are not affected. Users are advised to upgrade to version 1.1.5. Users unable to upgrade may unshare the cgroup namespace (`(docker|podman|nerdctl) run --cgroupns=private)`. This is the default behavior of Docker/Podman/nerdctl on cgroup v2 hosts. or add `/sys/fs/cgroup` to `maskedPaths`.(CVE-2023-25809)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.(CVE-2023-28642)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="docker-runc" release="13.oe2203sp1" version="1.1.3">
                         <filename>docker-runc-1.1.3-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="docker-runc" release="13.oe2203sp1" version="1.1.3">
                         <filename>docker-runc-1.1.3-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1205</id>
          <title>An update for sudo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28487" id="CVE-2023-28487" title="CVE-2023-28487" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28486" id="CVE-2023-28486" title="CVE-2023-28486" type="cve"></reference>
          </references>
          <description>Sudo before 1.9.13 does not escape control characters in sudoreplay output.(CVE-2023-28487)Sudo before 1.9.13 does not escape control characters in log messages.(CVE-2023-28486)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sudo-debugsource" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debugsource-1.9.8p2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-debuginfo" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debuginfo-1.9.8p2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-devel" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-devel-1.9.8p2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-1.9.8p2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sudo-help" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-help-1.9.8p2-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-debuginfo" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debuginfo-1.9.8p2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-1.9.8p2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-debugsource" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debugsource-1.9.8p2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-devel" release="11.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-devel-1.9.8p2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1206</id>
          <title>An update for glib2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25180" id="CVE-2023-25180" title="CVE-2023-25180" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24593" id="CVE-2023-24593" title="CVE-2023-24593" type="cve"></reference>
          </references>
          <description>glib: DoS caused by malicious serialised variant(CVE-2023-25180)glib: DoS caused by handling a malicious text-form variant(CVE-2023-24593)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glib2-debugsource" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-tests" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-tests-2.72.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-static" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-static-2.72.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-2.72.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debuginfo" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-devel" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-devel-2.72.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glib2-help" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-help-2.72.2-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debuginfo" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-2.72.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-tests" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-tests-2.72.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debugsource" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-devel" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-devel-2.72.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-static" release="10.oe2203sp1" version="2.72.2">
                         <filename>glib2-static-2.72.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1207</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"></reference>
          </references>
          <description>A security vulnerability has been identified in all supported versions of OpenSSL related to the verification of X.509 certificate chains that include policy constraints. Attackers may be able to exploit this vulnerability by creating a malicious certificate chain that triggers exponential use of computational resources, leading to a denial-of-service (DoS) attack on affected systems. Policy processing is disabled by default but can be enabled by passing the `-policy&#39; argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()&#39; function.(CVE-2023-0464)Applications that use a non-default option when verifying certificates may be vulnerable to an attack from a malicious CA to circumvent certain checks. Invalid certificate policies in leaf certificates are silently ignored by OpenSSL and other certificate policy checks are skipped for that certificate. A malicious CA could use this to deliberately assert invalid certificate policies in order to circumvent policy checking on the certificate altogether. Policy processing is disabled by default but can be enabled by passing the `-policy&#39; argument to the command line utilities or by calling the `X509_VERIFY_PARAM_set1_policies()&#39; function.(CVE-2023-0465)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-0466)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="20.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1208</id>
          <title>An update for hdf5 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-14031" id="CVE-2018-14031" title="CVE-2018-14031" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-16438" id="CVE-2018-16438" title="CVE-2018-16438" type="cve"></reference>
          </references>
          <description>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-14031)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-2018-16438)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hdf5-debuginfo" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debuginfo-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debugsource" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debugsource-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-devel-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-devel-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-devel-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-static" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-static-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-static" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-static-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-devel-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debuginfo" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debuginfo-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-devel-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-devel-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-static" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-static-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-static" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-static-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debugsource" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debugsource-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1209</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23004" id="CVE-2023-23004" title="CVE-2023-23004" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1249" id="CVE-2023-1249" title="CVE-2023-1249" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28327" id="CVE-2023-28327" title="CVE-2023-28327" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28328" id="CVE-2023-28328" title="CVE-2023-28328" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1380" id="CVE-2023-1380" title="CVE-2023-1380" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28466" id="CVE-2023-28466" title="CVE-2023-28466" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48424" id="CVE-2022-48424" title="CVE-2022-48424" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48423" id="CVE-2022-48423" title="CVE-2022-48423" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48425" id="CVE-2022-48425" title="CVE-2022-48425" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1513" id="CVE-2023-1513" title="CVE-2023-1513" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1281" id="CVE-2023-1281" title="CVE-2023-1281" type="cve"></reference>
          </references>
          <description>In the Linux kernel before 5.19, drivers/gpu/drm/arm/malidp_planes.c misinterprets the get_sg_table return value (expects it to be NULL in the error case, whereas it is actually an error pointer).(CVE-2023-23004)A use-after-free flaw was found in the Linux kernel’s core dump subsystem. This flaw allows a local user to crash the system. Only if patch 390031c94211 (&#34;coredump: Use the vma snapshot in fill_files_note&#34;) not applied yet, then kernel could be affected.(CVE-2023-1249)A null pointer dereference issue was found in the unix protocol in net/unix/diag.c in Linux before 6.0. In unix_diag_get_exact, the newly allocated skb does not have sk, leading to null pointer. A local user could use this flaw to crash the system or potentially cause a denial of service.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-28327)Kernel: A denial of service issue in  az6027 driver indrivers/media/usb/dev-usb/az6027.c(CVE-2023-28328)A slab-out-of-bound read problem was found in brcmf_get_assoc_ies 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-1380)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-28466)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-48424)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-48423)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-2022-48425)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-1513)Use After Free vulnerability in Linux kernel traffic control index filter (tcindex) allows Privilege Escalation. The imperfect hash area can be updated while packets are traversing, which will cause a use-after-free when &#39;tcf_exts_exec()&#39; is called with the destroyed tcf_ext. A local attacker user can use this vulnerability to elevate its privileges to root. This issue affects Linux Kernel: from 4.14 before git commit ee059170b1f7e94e55fa6cadee544e176a6e59c2.(CVE-2023-1281)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.27.0.103.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.27.0.103.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.27.0.103.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1213</id>
          <title>An update for zstd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4899" id="CVE-2022-4899" title="CVE-2022-4899" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-4899)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="zstd-devel" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-devel-1.5.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zstd-debugsource" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-debugsource-1.5.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zstd" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-1.5.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zstd-debuginfo" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-debuginfo-1.5.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="zstd-help" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-help-1.5.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zstd-devel" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-devel-1.5.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zstd-debuginfo" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-debuginfo-1.5.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zstd-debugsource" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-debugsource-1.5.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zstd" release="4.oe2203sp1" version="1.5.0">
                         <filename>zstd-1.5.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1216</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1611" id="CVE-2023-1611" title="CVE-2023-1611" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1670" id="CVE-2023-1670" title="CVE-2023-1670" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1859" id="CVE-2023-1859" title="CVE-2023-1859" type="cve"></reference>
          </references>
          <description>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-1611)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-1670)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-1859)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="kernel-debugsource" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.28.0.104.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.28.0.104.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.28.0.104.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1219</id>
          <title>An update for sqlite is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2022-12-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46908" id="CVE-2022-46908" title="CVE-2022-46908" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-46908)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sqlite-devel" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-devel-3.37.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite-debuginfo" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debuginfo-3.37.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite-debugsource" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debugsource-3.37.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-3.37.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sqlite-help" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-help-3.37.2-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-debuginfo" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debuginfo-3.37.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-devel" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-devel-3.37.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-debugsource" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debugsource-3.37.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite" release="5.oe2203sp1" version="3.37.2">
                         <filename>sqlite-3.37.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1220</id>
          <title>An update for libldb is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0614" id="CVE-2023-0614" title="CVE-2023-0614" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-0614)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libldb-debuginfo" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-debuginfo-2.6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libldb-debugsource" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-debugsource-2.6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-ldb-devel-common" release="2.oe2203sp1" version="2.6.1">
                         <filename>python-ldb-devel-common-2.6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libldb" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-2.6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-ldb" release="2.oe2203sp1" version="2.6.1">
                         <filename>python3-ldb-2.6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libldb-devel" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-devel-2.6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-ldb-devel" release="2.oe2203sp1" version="2.6.1">
                         <filename>python3-ldb-devel-2.6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libldb-help" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-help-2.6.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libldb-debugsource" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-debugsource-2.6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-ldb-devel-common" release="2.oe2203sp1" version="2.6.1">
                         <filename>python-ldb-devel-common-2.6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libldb" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-2.6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-ldb-devel" release="2.oe2203sp1" version="2.6.1">
                         <filename>python3-ldb-devel-2.6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libldb-debuginfo" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-debuginfo-2.6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libldb-devel" release="2.oe2203sp1" version="2.6.1">
                         <filename>libldb-devel-2.6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-ldb" release="2.oe2203sp1" version="2.6.1">
                         <filename>python3-ldb-2.6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1225</id>
          <title>An update for json-smart is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1370" id="CVE-2023-1370" title="CVE-2023-1370" type="cve"></reference>
          </references>
          <description>[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.(CVE-2023-1370)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="json-smart" release="2.oe2203sp1" version="2.2">
                         <filename>json-smart-2.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="json-smart-javadoc" release="2.oe2203sp1" version="2.2">
                         <filename>json-smart-javadoc-2.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1226</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28756" id="CVE-2023-28756" title="CVE-2023-28756" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28755" id="CVE-2023-28755" title="CVE-2023-28755" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-28756)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. The fixed versions are 0.12.1, 0.11.1, 0.10.2 and 0.10.0.1.(CVE-2023-28755)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="rubygem-json" release="129.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="129.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="129.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="129.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="129.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="129.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="129.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-power_assert" release="129.oe2203sp1" version="1.2.0">
                         <filename>rubygem-power_assert-1.2.0-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="129.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="129.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="129.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="129.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="129.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="129.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="129.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="129.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="129.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="129.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-129.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="129.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="129.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="129.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="129.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="129.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="129.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-129.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1227</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24329" id="CVE-2023-24329" title="CVE-2023-24329" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-24329)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-help-3.9.9-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="24.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1233</id>
          <title>An update for samba is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0225" id="CVE-2023-0225" title="CVE-2023-0225" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0922" id="CVE-2023-0922" title="CVE-2023-0922" type="cve"></reference>
          </references>
          <description>A flaw was found in Samba. An incomplete access check on dnsHostName allows authenticated but otherwise unprivileged users to delete this attribute from any object in the directory.(CVE-2023-0225)The Samba AD DC administration tool, when operating against a remote LDAP server, will by default send new or reset passwords over a signed-only connection.(CVE-2023-0922)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="samba-winbind" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-krb5-locator" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-krb5-locator-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ctdb" release="4.oe2203sp1" version="4.17.5">
                         <filename>ctdb-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-bind-dlz" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-bind-dlz-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-client-libs" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-client-libs-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient-devel" release="4.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-devel-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-modules" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-modules-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba" release="4.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-krb5-printing" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-krb5-printing-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debugsource" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-debugsource-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-dc" release="4.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-dc-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient" release="4.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common-tools" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-common-tools-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-clients" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-clients-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient" release="4.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-test" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-test-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-libs" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-libs-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-libs" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-libs-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-client" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-client-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debuginfo" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-debuginfo-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-provision" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-provision-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-common-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient-devel" release="4.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-devel-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-devel" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-devel-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-help" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-help-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-test" release="4.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-test-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-usershares" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-usershares-4.17.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="samba-pidl" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-pidl-4.17.5-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-krb5-printing" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-krb5-printing-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-bind-dlz" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-bind-dlz-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-usershares" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-usershares-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient" release="4.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-test" release="4.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-test-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ctdb" release="4.oe2203sp1" version="4.17.5">
                         <filename>ctdb-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient" release="4.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-common-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debugsource" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-debugsource-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-clients" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-clients-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-vfs-glusterfs" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-vfs-glusterfs-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-krb5-locator" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-krb5-locator-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-test" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-test-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba" release="4.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-libs" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-libs-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-modules" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-modules-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-provision" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-provision-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-client" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-client-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-help" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-help-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient-devel" release="4.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-devel-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-devel" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-devel-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-dc" release="4.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-dc-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common-tools" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-common-tools-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-libs" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-libs-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-client-libs" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-client-libs-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debuginfo" release="4.oe2203sp1" version="4.17.5">
                         <filename>samba-debuginfo-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient-devel" release="4.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-devel-4.17.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1234</id>
          <title>An update for openvswitch is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1668" id="CVE-2023-1668" title="CVE-2023-1668" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-1668)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openvswitch-debuginfo" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-help" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-devel" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-debugsource" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-help" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debuginfo" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debugsource" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-devel" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch" release="3.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1236</id>
          <title>An update for mod_auth_openidc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23527" id="CVE-2022-23527" title="CVE-2022-23527" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28625" id="CVE-2023-28625" title="CVE-2023-28625" type="cve"></reference>
          </references>
          <description>mod_auth_openidc is an OpenID Certified™ authentication and authorization module for the Apache 2.x HTTP server. Versions prior to 2.4.12.2 are vulnerable to Open Redirect. When providing a logout parameter to the redirect URI, the existing code in oidc_validate_redirect_url() does not properly check for URLs that start with /\t, leading to an open redirect. This issue has been patched in version 2.4.12.2. Users unable to upgrade can mitigate the issue by configuring mod_auth_openidc to only allow redirection when the destination matches a given regular expression with OIDCRedirectURLsAllowed.(CVE-2022-23527)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`.(CVE-2023-28625)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mod_auth_openidc-debugsource" release="1.oe2203sp1" version="2.4.13.2">
                         <filename>mod_auth_openidc-debugsource-2.4.13.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_auth_openidc" release="1.oe2203sp1" version="2.4.13.2">
                         <filename>mod_auth_openidc-2.4.13.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_auth_openidc-debuginfo" release="1.oe2203sp1" version="2.4.13.2">
                         <filename>mod_auth_openidc-debuginfo-2.4.13.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc-debugsource" release="1.oe2203sp1" version="2.4.13.2">
                         <filename>mod_auth_openidc-debugsource-2.4.13.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc-debuginfo" release="1.oe2203sp1" version="2.4.13.2">
                         <filename>mod_auth_openidc-debuginfo-2.4.13.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc" release="1.oe2203sp1" version="2.4.13.2">
                         <filename>mod_auth_openidc-2.4.13.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1237</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24536" id="CVE-2023-24536" title="CVE-2023-24536" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24534" id="CVE-2023-24534" title="CVE-2023-24534" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24538" id="CVE-2023-24538" title="CVE-2023-24538" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24537" id="CVE-2023-24537" title="CVE-2023-24537" type="cve"></reference>
          </references>
          <description>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-24536)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-24534)Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. &#34;var a = {{.}}&#34;), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution.(CVE-2023-24538)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-24537)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="16.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="16.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="16.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="16.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1238</id>
          <title>An update for docker is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28842" id="CVE-2023-28842" title="CVE-2023-28842" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28841" id="CVE-2023-28841" title="CVE-2023-28841" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28840" id="CVE-2023-28840" title="CVE-2023-28840" type="cve"></reference>
          </references>
          <description>Moby) is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*. Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code. The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet&#39;s VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. The `overlay` driver dynamically and lazily defines the kernel configuration for the VXLAN network on each node as containers are attached and detached. Routes and encryption parameters are only defined for destination nodes that participate in the network. The iptables rules that prevent encrypted overlay networks from accepting unencrypted packets are not created until a peer is available with which to communicate. Encrypted overlay networks silently accept cleartext VXLAN datagrams that are tagged with the VNI of an encrypted overlay network. As a result, it is possible to inject arbitrary Ethernet frames into the encrypted overlay network by encapsulating them in VXLAN datagrams. The implications of this can be quite dire, and GHSA-vwm3-crmr-xfxw should be referenced for a deeper exploration. Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime&#39;s 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. In multi-node clusters, deploy a global ‘pause’ container for each encrypted overlay network, on every node. For a single-node cluster, do not use overlay networks of any sort. Bridge networks provide the same connectivity on a single node and have no multi-node features. The Swarm ingress feature is implemented using an overlay network, but can be disabled by publishing ports in `host` mode instead of `ingress` mode (allowing the use of an external load balancer), and removing the `ingress` network. If encrypted overlay networks are in exclusive use, block UDP port 4789 from traffic that has not been validated by IPSec.(CVE-2023-28842)Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby is commonly referred to as *Docker*. Swarm Mode, which is compiled in and delivered by default in `dockerd` and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code. The `overlay` network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with the VXLAN metadata, including a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the `u32` iptables extension provided by the `xt_u32` kernel module to directly filter on a VXLAN packet&#39;s VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. An iptables rule designates outgoing VXLAN datagrams with a VNI that corresponds to an encrypted overlay network for IPsec encapsulation. Encrypted overlay networks on affected platforms silently transmit unencrypted data. As a result, `overlay` networks may appear to be functional, passing traffic as expected, but without any of the expected confidentiality or data integrity guarantees. It is possible for an attacker sitting in a trusted position on the network to read all of the application traffic that is moving across the overlay network, resulting in unexpected secrets or user data disclosure. Thus, because many database protocols, internal APIs, etc. are not protected by a second layer of encryption, a user may use Swarm encrypted overlay networks to provide confidentiality, which due to this vulnerability this is no longer guaranteed. Patches are available in Moby releases 23.0.3, and 20.10.24. As Mirantis Container Runtime&#39;s 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to outgoing traffic at the Internet boundary in order to prevent unintentionally leaking unencrypted traffic over the Internet, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.(CVE-2023-28841)Moby is an open source container framework developed by Docker Inc. that is distributed as Docker, Mirantis Container Runtime, and various other downstream projects/products. The Moby daemon component (`dockerd`), which is developed as moby/moby, is commonly referred to as *Docker*. Swarm Mode, which is compiled in and delivered by default in dockerd and is thus present in most major Moby downstreams, is a simple, built-in container orchestrator that is implemented through a combination of SwarmKit and supporting network code. The overlay network driver is a core feature of Swarm Mode, providing isolated virtual LANs that allow communication between containers and services across the cluster. This driver is an implementation/user of VXLAN, which encapsulates link-layer (Ethernet) frames in UDP datagrams that tag the frame with a VXLAN Network ID (VNI) that identifies the originating overlay network. In addition, the overlay network driver supports an optional, off-by-default encrypted mode, which is especially useful when VXLAN packets traverses an untrusted network between nodes. Encrypted overlay networks function by encapsulating the VXLAN datagrams through the use of the IPsec Encapsulating Security Payload protocol in Transport mode. By deploying IPSec encapsulation, encrypted overlay networks gain the additional properties of source authentication through cryptographic proof, data integrity through check-summing, and confidentiality through encryption. When setting an endpoint up on an encrypted overlay network, Moby installs three iptables (Linux kernel firewall) rules that enforce both incoming and outgoing IPSec. These rules rely on the u32 iptables extension provided by the xt_u32 kernel module to directly filter on a VXLAN packet&#39;s VNI field, so that IPSec guarantees can be enforced on encrypted overlay networks without interfering with other overlay networks or other users of VXLAN. Two iptables rules serve to filter incoming VXLAN datagrams with a VNI that corresponds to an encrypted network and discards unencrypted datagrams. The rules are appended to the end of the INPUT filter chain, following any rules that have been previously set by the system administrator. Administrator-set rules take precedence over the rules Moby sets to discard unencrypted VXLAN datagrams, which can potentially admit unencrypted datagrams that should have been discarded. The injection of arbitrary Ethernet frames can enable a Denial of Service attack. A sophisticated attacker may be able to establish a UDP or TCP connection by way of the container’s outbound gateway that would otherwise be blocked by a stateful firewall, or carry out other escalations beyond simple injection by smuggling packets into the overlay network. Patches are available in Moby releases 23.0.3 and 20.10.24. As Mirantis Container Runtime&#39;s 20.10 releases are numbered differently, users of that platform should update to 20.10.16. Some workarounds are available. Close the VXLAN port (by default, UDP port 4789) to incoming traffic at the Internet boundary to prevent all VXLAN packet injection, and/or ensure that the `xt_u32` kernel module is available on all nodes of the Swarm cluster.(CVE-2023-28840)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="docker-engine-debuginfo" release="323.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-323.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine" release="323.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-323.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debugsource" release="323.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-323.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debugsource" release="323.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-323.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine" release="323.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-323.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debuginfo" release="323.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-323.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1239</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1393" id="CVE-2023-1393" title="CVE-2023-1393" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-1393)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="18.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1240</id>
          <title>An update for avahi is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1981" id="CVE-2023-1981" title="CVE-2023-1981" type="cve"></reference>
          </references>
          <description>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.References:https://github.com/lathiat/avahi/issues/375(CVE-2023-1981)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="avahi-gobject-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-devel-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-howl-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-devel-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-ui-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-gobject" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-glib-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-glib-devel-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-autoipd" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-autoipd-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-glib" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-glib-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-libdns_sd-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-devel-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-dnsconfd" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-dnsconfd-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-libdns_sd" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-libs" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-libs-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-devel-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui-gtk3" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-ui-gtk3-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-howl" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-tools" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-tools-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-debugsource" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-debugsource-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-debuginfo" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-debuginfo-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-ui-devel-0.8-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="avahi-help" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-help-0.8-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-howl" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-libs" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-libs-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-howl-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-devel-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-gobject" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-glib-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-glib-devel-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-libdns_sd" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-ui-devel-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-autoipd" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-autoipd-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-ui-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-dnsconfd" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-dnsconfd-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-libdns_sd-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-devel-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-devel-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-debugsource" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-debugsource-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-glib" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-glib-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui-gtk3" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-ui-gtk3-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-gobject-devel" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-devel-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-tools" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-tools-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-debuginfo" release="15.oe2203sp1" version="0.8">
                         <filename>avahi-debuginfo-0.8-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1242</id>
          <title>An update for lua is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-45985" id="CVE-2021-45985" title="CVE-2021-45985" type="cve"></reference>
          </references>
          <description>In Lua 5.4.3, an erroneous finalizer called during a tail call leads to a heap-based buffer over-read.(CVE-2021-45985)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="lua-debugsource" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-debugsource-5.4.3-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lua-debuginfo" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-debuginfo-5.4.3-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lua" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-5.4.3-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lua-devel" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-devel-5.4.3-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="lua-help" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-help-5.4.3-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lua-debuginfo" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-debuginfo-5.4.3-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lua-debugsource" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-debugsource-5.4.3-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lua" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-5.4.3-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lua-devel" release="11.oe2203sp1" version="5.4.3">
                         <filename>lua-devel-5.4.3-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1244</id>
          <title>An update for tcpdump is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1801" id="CVE-2023-1801" title="CVE-2023-1801" type="cve"></reference>
          </references>
          <description>The SMB protocol decoder in tcpdump version 4.99.3 can perform an out-of-bounds write when decoding a crafted network packet.(CVE-2023-1801)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="tcpdump-help" release="6.oe2203sp1" version="4.99.1">
                         <filename>tcpdump-help-4.99.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="tcpdump" release="6.oe2203sp1" version="4.99.1">
                         <filename>tcpdump-4.99.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="tcpdump-debuginfo" release="6.oe2203sp1" version="4.99.1">
                         <filename>tcpdump-debuginfo-4.99.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="tcpdump-debugsource" release="6.oe2203sp1" version="4.99.1">
                         <filename>tcpdump-debugsource-4.99.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="tcpdump" release="6.oe2203sp1" version="4.99.1">
                         <filename>tcpdump-4.99.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="tcpdump-debugsource" release="6.oe2203sp1" version="4.99.1">
                         <filename>tcpdump-debugsource-4.99.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="tcpdump-debuginfo" release="6.oe2203sp1" version="4.99.1">
                         <filename>tcpdump-debuginfo-4.99.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="tcpdump-help" release="6.oe2203sp1" version="4.99.1">
                         <filename>tcpdump-help-4.99.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1245</id>
          <title>An update for nasm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44370" id="CVE-2022-44370" title="CVE-2022-44370" type="cve"></reference>
          </references>
          <description>NASM v2.16 was discovered to contain a heap buffer overflow in the component quote_for_pmake() asm/nasm.c:856(CVE-2022-44370)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nasm-debuginfo" release="5.oe2203sp1" version="2.15.05">
                         <filename>nasm-debuginfo-2.15.05-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nasm-debugsource" release="5.oe2203sp1" version="2.15.05">
                         <filename>nasm-debugsource-2.15.05-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nasm" release="5.oe2203sp1" version="2.15.05">
                         <filename>nasm-2.15.05-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="nasm-help" release="5.oe2203sp1" version="2.15.05">
                         <filename>nasm-help-2.15.05-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm-debuginfo" release="5.oe2203sp1" version="2.15.05">
                         <filename>nasm-debuginfo-2.15.05-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm-debugsource" release="5.oe2203sp1" version="2.15.05">
                         <filename>nasm-debugsource-2.15.05-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm" release="5.oe2203sp1" version="2.15.05">
                         <filename>nasm-2.15.05-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1246</id>
          <title>An update for freetype is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2004" id="CVE-2023-2004" title="CVE-2023-2004" type="cve"></reference>
          </references>
          <description>An integer overflow vulnerability was discovered in Freetype in tt_hvadvance_adjust() function in src/truetype/ttgxvar.c.(CVE-2023-2004)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="freetype-demos" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-demos-2.12.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freetype-debugsource" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-debugsource-2.12.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freetype" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-2.12.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freetype-devel" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-devel-2.12.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freetype-debuginfo" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-debuginfo-2.12.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="freetype-help" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-help-2.12.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype-debugsource" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-debugsource-2.12.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype-demos" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-demos-2.12.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype-devel" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-devel-2.12.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype-debuginfo" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-debuginfo-2.12.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freetype" release="2.oe2203sp1" version="2.12.1">
                         <filename>freetype-2.12.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1247</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28708" id="CVE-2023-28708" title="CVE-2023-28708" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-28708)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="30.oe2203sp1" version="9.0.10">
                         <filename>tomcat-jsvc-9.0.10-30.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat" release="30.oe2203sp1" version="9.0.10">
                         <filename>tomcat-9.0.10-30.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="30.oe2203sp1" version="9.0.10">
                         <filename>tomcat-help-9.0.10-30.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1249</id>
          <title>An update for bluez is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-27349" id="CVE-2023-27349" title="CVE-2023-27349" type="cve"></reference>
          </references>
          <description>(CVE-2023-27349)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bluez-debugsource" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-debugsource-5.54-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-cups" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-cups-5.54-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-debuginfo" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-debuginfo-5.54-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-5.54-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-devel" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-devel-5.54-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-libs" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-libs-5.54-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="bluez-help" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-help-5.54-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-debuginfo" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-debuginfo-5.54-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-devel" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-devel-5.54-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-5.54-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-debugsource" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-debugsource-5.54-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-libs" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-libs-5.54-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-cups" release="17.oe2203sp1" version="5.54">
                         <filename>bluez-cups-5.54-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1250</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1015" id="CVE-2022-1015" title="CVE-2022-1015" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36280" id="CVE-2022-36280" title="CVE-2022-36280" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-27672" id="CVE-2022-27672" title="CVE-2022-27672" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30456" id="CVE-2023-30456" title="CVE-2023-30456" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1989" id="CVE-2023-1989" title="CVE-2023-1989" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1829" id="CVE-2023-1829" title="CVE-2023-1829" type="cve"></reference>
          </references>
          <description>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-2022-1015)An out-of-bounds(OOB) memory access vulnerability was found in vmwgfx driver in drivers/gpu/vmxgfx/vmxgfx_kms.c in GPU component in the Linux kernel with device file &#39;/dev/dri/renderD128 (or Dxxx)&#39;. This flaw allows a local attacker with a user account on the system to gain privilege, causing a denial of service(DoS).(CVE-2022-36280)When SMT is enabled, certain AMD processors may speculatively execute instructions using a target from the sibling thread after an SMT mode switch potentially resulting in information disclosure.(CVE-2022-27672)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-30456)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-1989)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.We recommend upgrading past commit 8c710f75256bb3cf05ac7b1672c82b92c43f3d28.(CVE-2023-1829)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="kernel-source" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.29.0.105.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.29.0.105.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.29.0.105.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1254</id>
          <title>An update for hyperscan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29486" id="CVE-2022-29486" title="CVE-2022-29486" type="cve"></reference>
          </references>
          <description>Improper buffer restrictions in the Hyperscan library maintained by Intel(R) all versions downloaded before 04/29/2022 may allow an unauthenticated user to potentially enable escalation of privilege via network access.(CVE-2022-29486)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hyperscan-devel" release="3.oe2203sp1" version="5.4.0">
                         <filename>hyperscan-devel-5.4.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hyperscan-debugsource" release="3.oe2203sp1" version="5.4.0">
                         <filename>hyperscan-debugsource-5.4.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hyperscan-debuginfo" release="3.oe2203sp1" version="5.4.0">
                         <filename>hyperscan-debuginfo-5.4.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hyperscan" release="3.oe2203sp1" version="5.4.0">
                         <filename>hyperscan-5.4.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hyperscan-debuginfo" release="3.oe2203sp1" version="5.4.0">
                         <filename>hyperscan-debuginfo-5.4.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hyperscan-debugsource" release="3.oe2203sp1" version="5.4.0">
                         <filename>hyperscan-debugsource-5.4.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hyperscan" release="3.oe2203sp1" version="5.4.0">
                         <filename>hyperscan-5.4.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hyperscan-devel" release="3.oe2203sp1" version="5.4.0">
                         <filename>hyperscan-devel-5.4.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1257</id>
          <title>An update for haproxy is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25950" id="CVE-2023-25950" title="CVE-2023-25950" type="cve"></reference>
          </references>
          <description>HTTP request/response smuggling vulnerability in HAProxy version 2.7.0, and 2.6.1 to 2.6.7 allows a remote attacker to alter a legitimate user&#39;s request. As a result, the attacker may obtain sensitive information or cause a denial-of-service (DoS) condition.(CVE-2023-25950)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="haproxy" release="3.oe2203sp1" version="2.6.6">
                         <filename>haproxy-2.6.6-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debugsource" release="3.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debuginfo" release="3.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="haproxy-help" release="3.oe2203sp1" version="2.6.6">
                         <filename>haproxy-help-2.6.6-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debuginfo" release="3.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debugsource" release="3.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy" release="3.oe2203sp1" version="2.6.6">
                         <filename>haproxy-2.6.6-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1258</id>
          <title>An update for shadow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-04-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29383" id="CVE-2023-29383" title="CVE-2023-29383" type="cve"></reference>
          </references>
          <description>In Shadow 4.13, it is possible to inject control characters into fields provided to the SUID program chfn (change finger). Although it is not possible to exploit this directly (e.g., adding a new user fails because \n is in the block list), it is possible to misrepresent the /etc/passwd file when viewed. Use of \r manipulations and Unicode characters to work around blocking of the : character make it possible to give the impression that a new user has been added. In other words, an adversary may be able to convince a system administrator to take the system offline (an indirect, social-engineered denial of service) by demonstrating that &#34;cat /etc/passwd&#34; shows a rogue user account.(CVE-2023-29383)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="shadow-debuginfo" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-debuginfo-4.9-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow-subid-devel" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-subid-devel-4.9-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow-debugsource" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-debugsource-4.9-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-4.9-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="shadow-help" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-help-4.9-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-4.9-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-debugsource" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-debugsource-4.9-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-debuginfo" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-debuginfo-4.9-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-subid-devel" release="9.oe2203sp1" version="4.9">
                         <filename>shadow-subid-devel-4.9-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1259</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1289" id="CVE-2023-1289" title="CVE-2023-1289" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1906" id="CVE-2023-1906" title="CVE-2023-1906" type="cve"></reference>
          </references>
          <description>A vulnerability was discovered in ImageMagick where a specially created SVG file loads itself and causes a segmentation fault. This flaw allows a remote attacker to pass a specially crafted SVG file that leads to a segmentation fault, generating many trash files in &#34;/tmp,&#34; resulting in a denial of service. When ImageMagick crashes, it generates a lot of trash files. These trash files can be large if the SVG file contains many render actions. In a denial of service attack, if a remote attacker uploads an SVG file of size t, ImageMagick generates files of size 103*t. If an attacker uploads a 100M SVG, the server will generate about 10G.(CVE-2023-1289)A heap-based buffer overflow issue was discovered in ImageMagick&#39;s ImportMultiSpectralQuantum() function in MagickCore/quantum-import.c. An attacker could pass specially crafted file to convert, triggering an out-of-bounds read error, allowing an application to crash, resulting in a denial of service.(CVE-2023-1906)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1261</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1993" id="CVE-2023-1993" title="CVE-2023-1993" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1992" id="CVE-2023-1992" title="CVE-2023-1992" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1994" id="CVE-2023-1994" title="CVE-2023-1994" type="cve"></reference>
          </references>
          <description>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-1993)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-1992)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(CVE-2023-1994)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="3.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1262</id>
          <title>An update for libxml2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28484" id="CVE-2023-28484" title="CVE-2023-28484" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29469" id="CVE-2023-29469" title="CVE-2023-29469" type="cve"></reference>
          </references>
          <description>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-28484)An issue was discovered in libxml2 before 2.10.4. When hashing empty dict strings in a crafted XML document, xmlDictComputeFastKey in dict.c can produce non-deterministic values, leading to various logic and memory errors, such as a double free. This behavior occurs because there is an attempt to use the first byte of an empty string, and any value is possible (not solely the &#39;\0&#39; value).(CVE-2023-29469)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libxml2-debuginfo" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-devel" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-libxml2" release="5.oe2203sp1" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debugsource" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-2.9.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libxml2-help" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-help-2.9.14-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-devel" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libxml2" release="5.oe2203sp1" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debugsource" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debuginfo" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2" release="5.oe2203sp1" version="2.9.14">
                         <filename>libxml2-2.9.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1263</id>
          <title>An update for screen is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24626" id="CVE-2023-24626" title="CVE-2023-24626" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-24626)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="screen" release="2.oe2203sp1" version="4.9.0">
                         <filename>screen-4.9.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="screen-debugsource" release="2.oe2203sp1" version="4.9.0">
                         <filename>screen-debugsource-4.9.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="screen-debuginfo" release="2.oe2203sp1" version="4.9.0">
                         <filename>screen-debuginfo-4.9.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="screen-help" release="2.oe2203sp1" version="4.9.0">
                         <filename>screen-help-4.9.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="screen-debuginfo" release="2.oe2203sp1" version="4.9.0">
                         <filename>screen-debuginfo-4.9.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="screen-debugsource" release="2.oe2203sp1" version="4.9.0">
                         <filename>screen-debugsource-4.9.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="screen" release="2.oe2203sp1" version="4.9.0">
                         <filename>screen-4.9.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1264</id>
          <title>An update for dmidecode is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-04-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30630" id="CVE-2023-30630" title="CVE-2023-30630" type="cve"></reference>
          </references>
          <description>Dmidecode before 3.5 allows -dump-bin to overwrite a local file. This has security relevance because, for example, execution of Dmidecode via Sudo is plausible.(CVE-2023-30630)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="dmidecode-debugsource" release="3.oe2203sp1" version="3.4">
                         <filename>dmidecode-debugsource-3.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dmidecode" release="3.oe2203sp1" version="3.4">
                         <filename>dmidecode-3.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dmidecode-debuginfo" release="3.oe2203sp1" version="3.4">
                         <filename>dmidecode-debuginfo-3.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dmidecode-debuginfo" release="3.oe2203sp1" version="3.4">
                         <filename>dmidecode-debuginfo-3.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dmidecode-debugsource" release="3.oe2203sp1" version="3.4">
                         <filename>dmidecode-debugsource-3.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dmidecode" release="3.oe2203sp1" version="3.4">
                         <filename>dmidecode-3.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1265</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-04-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1855" id="CVE-2023-1855" title="CVE-2023-1855" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1990" id="CVE-2023-1990" title="CVE-2023-1990" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1872" id="CVE-2023-1872" title="CVE-2023-1872" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2006" id="CVE-2023-2006" title="CVE-2023-2006" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30772" id="CVE-2023-30772" title="CVE-2023-30772" type="cve"></reference>
          </references>
          <description>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-1855)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-1990)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 da24142b1ef9fd5d36b76e36bab328a5b27523e8.(CVE-2023-1872)A race condition was found in the Linux kernel&#39;s RxRPC network protocol, within the processing of RxRPC bundles. This issue results from the lack of proper locking when performing operations on an object. This may allow an attacker to escalate privileges and execute arbitrary code in the context of the kernel.(CVE-2023-2006)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.(CVE-2023-30772)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.30.0.106.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-devel" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.30.0.106.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.30.0.106.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1269</id>
          <title>An update for git is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25652" id="CVE-2023-25652" title="CVE-2023-25652" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25815" id="CVE-2023-25815" title="CVE-2023-25815" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29007" id="CVE-2023-29007" title="CVE-2023-29007" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-25652)In Git for Windows, the Windows port of Git, no localized messages are shipped with the installer. As a consequence, Git is expected not to localize messages at all, and skips the gettext initialization. However, due to a change in MINGW-packages, the `gettext()` function&#39;s implicit initialization no longer uses the runtime prefix but uses the hard-coded path `C:\mingw64\share\locale` to look for localized messages. And since any authenticated user has the permission to create folders in `C:\` (and since `C:\mingw64` does not typically exist), it is possible for low-privilege users to place fake messages in that location where `git.exe` will pick them up in version 2.40.1.This vulnerability is relatively hard to exploit and requires social engineering. For example, a legitimate message at the end of a clone could be maliciously modified to ask the user to direct their web browser to a malicious website, and the user might think that the message comes from Git and is legitimate. It does require local write access by the attacker, though, which makes this attack vector less likely. Version 2.40.1 contains a patch for this issue. Some workarounds are available. Do not work on a Windows machine with shared accounts, or alternatively create a `C:\mingw64` folder and leave it empty. Users who have administrative rights may remove the permission to create folders in `C:\`.(CVE-2023-25815)Git is a revision control system. Prior to versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1, a specially crafted `.gitmodules` file with submodule URLs that are longer than 1024 characters can used to exploit a bug in `config.c::git_config_copy_or_rename_section_in_file()`. This bug can be used to inject arbitrary configuration into a user&#39;s `$GIT_DIR/config` when attempting to remove the configuration section associated with that submodule. When the attacker injects configuration values which specify executables to run (such as `core.pager`, `core.editor`, `core.sshCommand`, etc.) this can lead to a remote code execution. A fix A fix is available in versions 2.30.9, 2.31.8, 2.32.7, 2.33.8, 2.34.8, 2.35.8, 2.36.6, 2.37.7, 2.38.5, 2.39.3, and 2.40.1. As a workaround, avoid running `git submodule deinit` on untrusted repositories or without prior inspection of any submodule sections in `$GIT_DIR/config`.(CVE-2023-29007)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="git" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-daemon" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debuginfo" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debugsource" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-core" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-svn" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-svn-2.33.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git" release="11.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-2.33.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-web" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-web-2.33.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git-SVN" release="11.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-SVN-2.33.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-email" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-email-2.33.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-help" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-help-2.33.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-gui" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-gui-2.33.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="gitk" release="11.oe2203sp1" version="2.33.0">
                         <filename>gitk-2.33.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debuginfo" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-daemon" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-core" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debugsource" release="11.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1275</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4382" id="CVE-2022-4382" title="CVE-2022-4382" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1998" id="CVE-2023-1998" title="CVE-2023-1998" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2007" id="CVE-2023-2007" title="CVE-2023-2007" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2166" id="CVE-2023-2166" title="CVE-2023-2166" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2176" id="CVE-2023-2176" title="CVE-2023-2176" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2194" id="CVE-2023-2194" title="CVE-2023-2194" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2269" id="CVE-2023-2269" title="CVE-2023-2269" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0458" id="CVE-2023-0458" title="CVE-2023-0458" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31436" id="CVE-2023-31436" title="CVE-2023-31436" type="cve"></reference>
          </references>
          <description>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-2022-4382)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-1998)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.(CVE-2023-2007)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-2166)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-2176)An out-of-bounds write vulnerability was found in the Linux kernel&#39;s SLIMpro I2C device driver. The userspace &#34;data-&gt;block[0]&#34; variable was not capped to a number between 0-255 and was used as the size of a memcpy, possibly writing beyond the end of dma_buffer. This flaw could allow a local privileged user to crash the system or potentially achieve code execution.(CVE-2023-2194)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-2269)A speculative pointer dereference problem exists in the Linux Kernel on the do_prlimit() function. The resource argument value is controlled and is used in pointer arithmetic for the &#39;rlim&#39; variable and can be used to leak the contents. We recommend upgrading past version 6.1.8 or commit 739790605705ddcf18f21782b9c99ad7d53a8c11(CVE-2023-0458)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-31436)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="bpftool" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.31.0.107.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="504" arch="x86_64" name="python3-perf-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.31.0.107.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.31.0.107.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1278</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-05-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2426" id="CVE-2023-2426" title="CVE-2023-2426" type="cve"></reference>
          </references>
          <description>Use of Out-of-range Pointer Offset in GitHub repository vim/vim prior to 9.0.1499.(CVE-2023-2426)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="14.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="14.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="14.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="14.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="14.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="14.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="14.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="14.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="14.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="14.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="14.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="14.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="14.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1279</id>
          <title>An update for python-sqlparse is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30608" id="CVE-2023-30608" title="CVE-2023-30608" type="cve"></reference>
          </references>
          <description>sqlparse is a non-validating SQL parser module for Python. In affected versions the SQL parser contains a regular expression that is vulnerable to ReDoS (Regular Expression Denial of Service). This issue was introduced by commit `e75e358`. The vulnerability may lead to Denial of Service (DoS). This issues has been fixed in sqlparse 0.4.4 by commit `c457abd5f`. Users are advised to upgrade. There are no known workarounds for this issue.(CVE-2023-30608)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-sqlparse-help" release="2.oe2203sp1" version="0.4.2">
                         <filename>python-sqlparse-help-0.4.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-sqlparse" release="2.oe2203sp1" version="0.4.2">
                         <filename>python3-sqlparse-0.4.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1280</id>
          <title>An update for LibRaw is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1729" id="CVE-2023-1729" title="CVE-2023-1729" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-1729)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="LibRaw" release="6.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-0.20.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw-debuginfo" release="6.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-debuginfo-0.20.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw-devel" release="6.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-devel-0.20.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw-debugsource" release="6.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-debugsource-0.20.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-debuginfo" release="6.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-debuginfo-0.20.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-devel" release="6.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-devel-0.20.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-debugsource" release="6.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-debugsource-0.20.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw" release="6.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-0.20.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1281</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2609" id="CVE-2023-2609" title="CVE-2023-2609" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2610" id="CVE-2023-2610" title="CVE-2023-2610" type="cve"></reference>
          </references>
          <description>NULL Pointer Dereference in GitHub repository vim/vim prior to 9.0.1531.(CVE-2023-2609)Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1532.(CVE-2023-2610)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="15.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="15.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="15.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="15.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="15.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="15.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="15.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="15.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="15.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="15.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="15.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="15.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="15.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1282</id>
          <title>An update for ntp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26551" id="CVE-2023-26551" title="CVE-2023-26551" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26554" id="CVE-2023-26554" title="CVE-2023-26554" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26553" id="CVE-2023-26553" title="CVE-2023-26553" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26552" id="CVE-2023-26552" title="CVE-2023-26552" type="cve"></reference>
          </references>
          <description>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-26551)mstolfp in libntp/mstolfp.c in NTP 4.2.8p15 has an out-of-bounds write when adding a &#39;\0&#39; character. An adversary may be able to attack a client ntpq process, but cannot attack ntpd.(CVE-2023-26554)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-26553)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-26552)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ntp-debugsource" release="9.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-debugsource-4.2.8p15-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ntp" release="9.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-4.2.8p15-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ntp-debuginfo" release="9.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-debuginfo-4.2.8p15-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ntp-help" release="9.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-help-4.2.8p15-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ntp-perl" release="9.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-perl-4.2.8p15-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ntp-debuginfo" release="9.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-debuginfo-4.2.8p15-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ntp" release="9.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-4.2.8p15-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ntp-debugsource" release="9.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-debugsource-4.2.8p15-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1283</id>
          <title>An update for openjdk-11 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
          </references>
          <description>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-21930)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debugsource" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-debugsource-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-jmods-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-javadoc-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc-zip" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-javadoc-zip-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-devel-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-slowdebug-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-demo-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-headless-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-src-slowdebug-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debuginfo" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-debuginfo-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-src-11.0.19.7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-src-slowdebug-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debuginfo" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-debuginfo-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-javadoc-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-slowdebug-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-demo-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-devel-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debugsource" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-debugsource-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc-zip" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-javadoc-zip-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-headless-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-jmods-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo-slowdebug" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src" release="3.oe2203sp1" version="11.0.19.7">
                         <filename>java-11-openjdk-src-11.0.19.7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1284</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2002" id="CVE-2023-2002" title="CVE-2023-2002" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0458" id="CVE-2023-0458" title="CVE-2023-0458" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2483" id="CVE-2023-2483" title="CVE-2023-2483" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32269" id="CVE-2023-32269" title="CVE-2023-32269" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26544" id="CVE-2023-26544" title="CVE-2023-26544" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0459" id="CVE-2023-0459" title="CVE-2023-0459" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2177" id="CVE-2023-2177" title="CVE-2023-2177" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2513" id="CVE-2023-2513" title="CVE-2023-2513" type="cve"></reference>
          </references>
          <description>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-2002)A speculative pointer dereference problem exists in the Linux Kernel on the do_prlimit() function. The resource argument value is controlled and is used in pointer arithmetic for the &#39;rlim&#39; variable and can be used to leak the contents. We recommend upgrading past version 6.1.8 or commit 739790605705ddcf18f21782b9c99ad7d53a8c11(CVE-2023-0458)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.Upstream fix:https://github.com/torvalds/linux/commit/6b6bc5b8bd2d(CVE-2023-2483)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-32269)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-26544)No description is available for this CVE(CVE-2023-0459)A null pointer dereference issue was found in the sctp network protocol in net/sctp/stream_sched.c in Linux Kernel. If stream_in allocation is failed, stream_out is freed which would further be accessed. A local user could use this flaw to crash the system or potentially cause a denial of service.(CVE-2023-2177)A use-after-free vulnerability was found in the Linux kernel&#39;s ext4 filesystem in the way it handled the extra inode size for extended attributes. This flaw could allow a privileged local user to cause a system crash or other undefined behaviors.(CVE-2023-2513)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.32.0.108.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.32.0.108.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.32.0.108.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1285</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37434" id="CVE-2022-37434" title="CVE-2022-37434" type="cve"></reference>
          </references>
          <description>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).(CVE-2022-37434)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql-test" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-test-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-help-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-server-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-debugsource-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-devel-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-debuginfo-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-config-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-common-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-libs-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-errmsg-8.0.29-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-config-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-devel-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-server-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-help-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-libs-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-common-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-test-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-errmsg-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-debugsource-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="2.oe2203sp1" version="8.0.29">
                         <filename>mysql-debuginfo-8.0.29-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1286</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31047" id="CVE-2023-31047" title="CVE-2023-31047" type="cve"></reference>
          </references>
          <description>In Django 3.2 before 3.2.19, 4.x before 4.1.9, and 4.2 before 4.2.1, it was possible to bypass validation when using one form field to upload multiple files. This multiple upload has never been supported by forms.FileField or forms.ImageField (only the last uploaded file was validated). However, Django&#39;s &#34;Uploading multiple files&#34; documentation suggested otherwise.(CVE-2023-31047)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-Django" release="4.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-django-help" release="4.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1287</id>
          <title>An update for perl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31484" id="CVE-2023-31484" title="CVE-2023-31484" type="cve"></reference>
          </references>
          <description>CPAN.pm before 2.35 does not verify TLS certificates when downloading distributions over HTTPS.(CVE-2023-31484)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="4" arch="aarch64" name="perl-debugsource" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-libs" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-devel" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debuginfo" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="noarch" name="perl-help" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-help-5.34.0-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-libs" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debugsource" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debuginfo" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-devel" release="7.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1288</id>
          <title>An update for openjdk-1.8.0 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
          </references>
          <description>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-21967)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-src-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.372.b07-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc-zip" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.372.b07-0.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-javadoc-1.8.0.372.b07-0.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-src-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk" release="0.oe2203sp1" version="1.8.0.372.b07">
                         <filename>java-1.8.0-openjdk-1.8.0.372.b07-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1289</id>
          <title>An update for redis is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28856" id="CVE-2023-28856" title="CVE-2023-28856" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-28856)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="redis-debuginfo" release="5.oe2203sp1" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis" release="5.oe2203sp1" version="4.0.14">
                         <filename>redis-4.0.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debugsource" release="5.oe2203sp1" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debugsource" release="5.oe2203sp1" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debuginfo" release="5.oe2203sp1" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis" release="5.oe2203sp1" version="4.0.14">
                         <filename>redis-4.0.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1290</id>
          <title>An update for cloud-init is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-05-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2084" id="CVE-2022-2084" title="CVE-2022-2084" type="cve"></reference>
          </references>
          <description>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-2022-2084)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="cloud-init-help" release="14.oe2203sp1" version="21.4">
                         <filename>cloud-init-help-21.4-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cloud-init" release="14.oe2203sp1" version="21.4">
                         <filename>cloud-init-21.4-14.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1292</id>
          <title>An update for ntp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-05-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26555" id="CVE-2023-26555" title="CVE-2023-26555" type="cve"></reference>
          </references>
          <description>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-26555)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ntp-debugsource" release="10.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-debugsource-4.2.8p15-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ntp-debuginfo" release="10.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-debuginfo-4.2.8p15-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ntp" release="10.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-4.2.8p15-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ntp-perl" release="10.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-perl-4.2.8p15-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ntp-help" release="10.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-help-4.2.8p15-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ntp-debuginfo" release="10.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-debuginfo-4.2.8p15-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ntp" release="10.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-4.2.8p15-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ntp-debugsource" release="10.oe2203sp1" version="4.2.8p15">
                         <filename>ntp-debugsource-4.2.8p15-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1293</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2162" id="CVE-2023-2162" title="CVE-2023-2162" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2124" id="CVE-2023-2124" title="CVE-2023-2124" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32233" id="CVE-2023-32233" title="CVE-2023-32233" type="cve"></reference>
          </references>
          <description>A use-after-free vulnerability was found in iscsi_sw_tcp_session_create in drivers/scsi/iscsi_tcp.c in SCSI sub-component in the Linux Kernel. In this flaw an attacker could leak kernel internal information.(CVE-2023-2162)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-2124)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-32233)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-devel" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="perf" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.33.0.109.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-source" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.33.0.109.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.33.0.109.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1294</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29400" id="CVE-2023-29400" title="CVE-2023-29400" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24539" id="CVE-2023-24539" title="CVE-2023-24539" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24540" id="CVE-2023-24540" title="CVE-2023-24540" type="cve"></reference>
          </references>
          <description>Templates containing actions in unquoted HTML attributes (e.g. &#34;attr={{.}}&#34;) executed with empty input can result in output with unexpected results when parsed due to HTML normalization rules. This may allow injection of arbitrary attributes into tags.(CVE-2023-29400)Angle brackets (&lt;&gt;) are not considered dangerous characters when inserted into CSS contexts. Templates containing multiple actions separated by a &#39;/&#39; character can result in unexpectedly closing the CSS context and allowing for injection of unexpected HTML, if executed with untrusted input.(CVE-2023-24539)Not all valid JavaScript whitespace characters are considered to be whitespace. Templates containing whitespace characters outside of the character set &#34;\t\n\f\r\u0020\u2028\u2029&#34; in JavaScript contexts that also contain actions may not be properly sanitized during execution.(CVE-2023-24540)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="18.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="18.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="18.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="18.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1297</id>
          <title>An update for cloud-init is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-05-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1786" id="CVE-2023-1786" title="CVE-2023-1786" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-1786)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="cloud-init" release="16.oe2203sp1" version="21.4">
                         <filename>cloud-init-21.4-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cloud-init-help" release="16.oe2203sp1" version="21.4">
                         <filename>cloud-init-help-21.4-16.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1298</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1050" id="CVE-2022-1050" title="CVE-2022-1050" type="cve"></reference>
          </references>
          <description>A flaw was found in the QEMU implementation of VMWare&#39;s paravirtual RDMA device. This flaw allows a crafted guest driver to execute HW commands when shared buffers are not yet allocated, potentially leading to a use-after-free condition.(CVE-2022-1050)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="qemu" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-system-arm" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-hw-usb-host" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-debugsource" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-img" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-block-curl" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-guest-agent" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-block-rbd" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-debuginfo" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-system-aarch64" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-system-riscv" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-block-ssh" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-system-x86_64" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qemu-block-iscsi" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-74.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="qemu-help" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-74.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-debuginfo" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-block-curl" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-block-ssh" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-system-aarch64" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-hw-usb-host" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-debugsource" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-block-rbd" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-system-arm" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-img" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-seabios" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-block-iscsi" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-guest-agent" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-system-riscv" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qemu-system-x86_64" release="74.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-74.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1299</id>
          <title>An update for libtpms is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-05-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1018" id="CVE-2023-1018" title="CVE-2023-1018" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1017" id="CVE-2023-1017" title="CVE-2023-1017" type="cve"></reference>
          </references>
          <description>An out-of-bounds read vulnerability exists in TPM2.0&#39;s Module Library allowing a 2-byte read past the end of a TPM2.0 command in the CryptParameterDecryption routine. An attacker who can successfully exploit this vulnerability can read or access sensitive data stored in the TPM.(CVE-2023-1018)An out-of-bounds write vulnerability exists in TPM2.0&#39;s Module Library allowing writing of a 2-byte data past the end of TPM2.0 command in the CryptParameterDecryption routine. An attacker who can successfully exploit this vulnerability can lead to denial of service (crashing the TPM chip/process or rendering it unusable) and/or arbitrary code execution in the TPM context.(CVE-2023-1017)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtpms" release="8.oe2203sp1" version="0.7.3">
                         <filename>libtpms-0.7.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtpms-devel" release="8.oe2203sp1" version="0.7.3">
                         <filename>libtpms-devel-0.7.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtpms-debugsource" release="8.oe2203sp1" version="0.7.3">
                         <filename>libtpms-debugsource-0.7.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtpms-debuginfo" release="8.oe2203sp1" version="0.7.3">
                         <filename>libtpms-debuginfo-0.7.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtpms-debugsource" release="8.oe2203sp1" version="0.7.3">
                         <filename>libtpms-debugsource-0.7.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtpms-debuginfo" release="8.oe2203sp1" version="0.7.3">
                         <filename>libtpms-debuginfo-0.7.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtpms-devel" release="8.oe2203sp1" version="0.7.3">
                         <filename>libtpms-devel-0.7.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtpms" release="8.oe2203sp1" version="0.7.3">
                         <filename>libtpms-0.7.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1301</id>
          <title>An update for sysstat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33204" id="CVE-2023-33204" title="CVE-2023-33204" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-33204)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sysstat-debuginfo" release="7.oe2203sp1" version="12.5.4">
                         <filename>sysstat-debuginfo-12.5.4-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sysstat-debugsource" release="7.oe2203sp1" version="12.5.4">
                         <filename>sysstat-debugsource-12.5.4-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sysstat" release="7.oe2203sp1" version="12.5.4">
                         <filename>sysstat-12.5.4-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sysstat-debugsource" release="7.oe2203sp1" version="12.5.4">
                         <filename>sysstat-debugsource-12.5.4-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sysstat" release="7.oe2203sp1" version="12.5.4">
                         <filename>sysstat-12.5.4-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sysstat-debuginfo" release="7.oe2203sp1" version="12.5.4">
                         <filename>sysstat-debuginfo-12.5.4-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1305</id>
          <title>An update for libssh is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1667" id="CVE-2023-1667" title="CVE-2023-1667" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2283" id="CVE-2023-2283" title="CVE-2023-2283" type="cve"></reference>
          </references>
          <description>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-1667)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.(CVE-2023-2283)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libssh-debugsource" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-debugsource-0.9.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-0.9.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh-devel" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-devel-0.9.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh-debuginfo" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-debuginfo-0.9.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libssh-help" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-help-0.9.6-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-0.9.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-devel" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-devel-0.9.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-debugsource" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-debugsource-0.9.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-debuginfo" release="7.oe2203sp1" version="0.9.6">
                         <filename>libssh-debuginfo-0.9.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1310</id>
          <title>An update for webkit2gtk3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32373" id="CVE-2023-32373" title="CVE-2023-32373" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28204" id="CVE-2023-28204" title="CVE-2023-28204" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32409" id="CVE-2023-32409" title="CVE-2023-32409" type="cve"></reference>
          </references>
          <description>A use after free vulnerability was found in the webkitgtk package. Processing maliciously crafted web content may lead to arbitrary code execution.(CVE-2023-32373)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-28204)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.(CVE-2023-32409)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="webkit2gtk3-jsc" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-jsc-2.36.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-debuginfo" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-debuginfo-2.36.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-devel" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-devel-2.36.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-debugsource" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-debugsource-2.36.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-jsc-devel" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-jsc-devel-2.36.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-2.36.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="webkit2gtk3-help" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-help-2.36.3-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-jsc" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-jsc-2.36.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-2.36.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-debuginfo" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-debuginfo-2.36.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-jsc-devel" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-jsc-devel-2.36.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-debugsource" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-debugsource-2.36.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-devel" release="4.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-devel-2.36.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1313</id>
          <title>An update for c-ares is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32067" id="CVE-2023-32067" title="CVE-2023-32067" type="cve"></reference>
          </references>
          <description>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-32067)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.(CVE-2023-31147)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="c-ares-debuginfo" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-devel" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-debugsource" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="c-ares-help" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-help-1.18.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debuginfo" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-devel" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debugsource" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares" release="6.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1315</id>
          <title>An update for cups-filters is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24805" id="CVE-2023-24805" title="CVE-2023-24805" type="cve"></reference>
          </references>
          <description>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. This issue has been addressed in commit `8f2740357` and is expected to be bundled in the next release. Users are advised to upgrade when possible and to restrict access to network printers in the meantime.(CVE-2023-24805)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cups-filters-devel" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-devel-1.28.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters-debugsource" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-debugsource-1.28.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters-debuginfo" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-debuginfo-1.28.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-1.28.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cups-filters-help" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-help-1.28.9-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-1.28.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-debugsource" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-debugsource-1.28.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-devel" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-devel-1.28.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-debuginfo" release="3.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-debuginfo-1.28.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1316</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2731" id="CVE-2023-2731" title="CVE-2023-2731" type="cve"></reference>
          </references>
          <description>A NULL pointer dereference flaw was found in Libtiff&#39;s LZWDecode() function in the libtiff/tif_lzw.c file. This flaw allows a local attacker to craft specific input data that can cause the program to dereference a NULL pointer when decompressing a TIFF format file, resulting in a program crash or denial of service.(CVE-2023-2731)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-tools" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="25.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1317</id>
          <title>An update for libwebp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1999" id="CVE-2023-1999" title="CVE-2023-1999" type="cve"></reference>
          </references>
          <description>A vulnerability was found in libwebp (affected version unknown). It has been declared as critical. Affected by this vulnerability is an unknown code of the component Image File Handler. There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.(CVE-2023-1999)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libwebp" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-1.2.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-debugsource" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-debugsource-1.2.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-java" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-java-1.2.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-debuginfo" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-debuginfo-1.2.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-tools" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-tools-1.2.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-devel" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-devel-1.2.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libwebp-help" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-help-1.2.1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-1.2.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-debuginfo" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-debuginfo-1.2.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-devel" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-devel-1.2.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-tools" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-tools-1.2.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-debugsource" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-debugsource-1.2.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-java" release="3.oe2203sp1" version="1.2.1">
                         <filename>libwebp-java-1.2.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1318</id>
          <title>An update for libreswan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30570" id="CVE-2023-30570" title="CVE-2023-30570" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-30570)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libreswan" release="1.oe2203sp1" version="4.11">
                         <filename>libreswan-4.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-help" release="1.oe2203sp1" version="4.11">
                         <filename>libreswan-help-4.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debuginfo" release="1.oe2203sp1" version="4.11">
                         <filename>libreswan-debuginfo-4.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debugsource" release="1.oe2203sp1" version="4.11">
                         <filename>libreswan-debugsource-4.11-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debuginfo" release="1.oe2203sp1" version="4.11">
                         <filename>libreswan-debuginfo-4.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debugsource" release="1.oe2203sp1" version="4.11">
                         <filename>libreswan-debugsource-4.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan" release="1.oe2203sp1" version="4.11">
                         <filename>libreswan-4.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-help" release="1.oe2203sp1" version="4.11">
                         <filename>libreswan-help-4.11-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1322</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2857" id="CVE-2023-2857" title="CVE-2023-2857" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2858" id="CVE-2023-2858" title="CVE-2023-2858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2855" id="CVE-2023-2855" title="CVE-2023-2855" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0668" id="CVE-2023-0668" title="CVE-2023-0668" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2856" id="CVE-2023-2856" title="CVE-2023-2856" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2879" id="CVE-2023-2879" title="CVE-2023-2879" type="cve"></reference>
          </references>
          <description>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-2857)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-2858)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-2855)A flaw was found in the IEEE C37.118 Synchrophasor dissector of Wireshark. This issue occurs when decoding malformed packets from a pcap file or from the network, causing a buffer overflow, resulting in a denial of service.(CVE-2023-0668)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-2856)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(CVE-2023-2879)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-help-3.6.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debugsource-3.6.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-devel-3.6.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-3.6.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="4.oe2203sp1" version="3.6.11">
                         <filename>wireshark-debuginfo-3.6.11-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1324</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22998" id="CVE-2023-22998" title="CVE-2023-22998" type="cve"></reference>
          </references>
          <description>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-22998)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.34.0.110.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.34.0.110.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.34.0.110.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1327</id>
          <title>An update for hdf5 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-06-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-8396" id="CVE-2019-8396" title="CVE-2019-8396" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-13867" id="CVE-2018-13867" title="CVE-2018-13867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-37501" id="CVE-2021-37501" title="CVE-2021-37501" type="cve"></reference>
          </references>
          <description>A buffer overflow in H5O__layout_encode in H5Olayout.c in the HDF HDF5 through 1.10.4 library allows attackers to cause a denial of service via a crafted HDF5 file. This issue was triggered while repacking an HDF5 file, aka &#34;Invalid write of size 2.&#34;(CVE-2019-8396)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-13867)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.(CVE-2021-37501)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hdf5-mpich-static" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-static-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debugsource" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debugsource-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-devel-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debuginfo" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debuginfo-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-devel-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-devel-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-static" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-static-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-1.12.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-static" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-static-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-devel-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-static" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-static-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debuginfo" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debuginfo-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-devel-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debugsource" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debugsource-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-devel" release="4.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-devel-1.12.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1333</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2157" id="CVE-2023-2157" title="CVE-2023-2157" type="cve"></reference>
          </references>
          <description>A heap-based buffer overflow vulnerability was found in the ImageMagick package that can lead to the application crashing.(CVE-2023-2157)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="1.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1334</id>
          <title>An update for openldap is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2953" id="CVE-2023-2953" title="CVE-2023-2953" type="cve"></reference>
          </references>
          <description>A vulnerability was found in openldap. This security flaw causes a null pointer dereference in ber_memalloc_x() function.(CVE-2023-2953)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openldap" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-2.6.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openldap-clients" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-clients-2.6.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openldap-devel" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-devel-2.6.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openldap-servers" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-servers-2.6.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openldap-debugsource" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-debugsource-2.6.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openldap-debuginfo" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-debuginfo-2.6.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openldap-help" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-help-2.6.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openldap-debuginfo" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-debuginfo-2.6.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openldap" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-2.6.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openldap-debugsource" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-debugsource-2.6.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openldap-clients" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-clients-2.6.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openldap-devel" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-devel-2.6.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openldap-servers" release="6.oe2203sp1" version="2.6.0">
                         <filename>openldap-servers-2.6.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1335</id>
          <title>An update for cups is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32324" id="CVE-2023-32324" title="CVE-2023-32324" type="cve"></reference>
          </references>
          <description>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`. No known patches or workarounds exist at time of publication.(CVE-2023-32324)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cups-ipptool" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-debugsource" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-debuginfo" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-devel" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-printerapp" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-client" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-lpd" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-libs" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cups-help" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-help-2.4.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cups-filesystem" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-filesystem-2.4.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-printerapp" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-client" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-ipptool" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-devel" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-libs" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-debuginfo" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-lpd" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-debugsource" release="6.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1338</id>
          <title>An update for cpio is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-06-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-1197" id="CVE-2015-1197" title="CVE-2015-1197" type="cve"></reference>
          </references>
          <description>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.(CVE-2015-1197)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cpio" release="8.oe2203sp1" version="2.13">
                         <filename>cpio-2.13-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cpio-debuginfo" release="8.oe2203sp1" version="2.13">
                         <filename>cpio-debuginfo-2.13-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cpio-debugsource" release="8.oe2203sp1" version="2.13">
                         <filename>cpio-debugsource-2.13-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cpio-help" release="8.oe2203sp1" version="2.13">
                         <filename>cpio-help-2.13-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cpio-debuginfo" release="8.oe2203sp1" version="2.13">
                         <filename>cpio-debuginfo-2.13-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cpio" release="8.oe2203sp1" version="2.13">
                         <filename>cpio-2.13-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cpio-debugsource" release="8.oe2203sp1" version="2.13">
                         <filename>cpio-debugsource-2.13-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1340</id>
          <title>An update for c-ares is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31147" id="CVE-2023-31147" title="CVE-2023-31147" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-31147)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="c-ares-devel" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-debugsource" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-debuginfo" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="c-ares-help" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-help-1.18.1-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debugsource" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-devel" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debuginfo" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1341</id>
          <title>An update for python-requests is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32681" id="CVE-2023-32681" title="CVE-2023-32681" type="cve"></reference>
          </references>
          <description>Requests is a HTTP library. Since Requests 2.3.0, Requests has been leaking Proxy-Authorization headers to destination servers when redirected to an HTTPS endpoint. This is a product of how we use `rebuild_proxies` to reattach the `Proxy-Authorization` header to requests. For HTTP connections sent through the tunnel, the proxy will identify the header in the request itself and remove it prior to forwarding to the destination server. However when sent over HTTPS, the `Proxy-Authorization` header must be sent in the CONNECT request as the proxy has no visibility into the tunneled request. This results in Requests forwarding proxy credentials to the destination server unintentionally, allowing a malicious actor to potentially exfiltrate sensitive information. This issue has been patched in version 2.31.0.(CVE-2023-32681)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-requests-help" release="8.oe2203sp1" version="2.26.0">
                         <filename>python-requests-help-2.26.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-requests" release="8.oe2203sp1" version="2.26.0">
                         <filename>python3-requests-2.26.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1342</id>
          <title>An update for libcap is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2602" id="CVE-2023-2602" title="CVE-2023-2602" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2603" id="CVE-2023-2603" title="CVE-2023-2603" type="cve"></reference>
          </references>
          <description>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-2602)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.(CVE-2023-2603)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libcap-devel" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-devel-2.61-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcap" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-2.61-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcap-debugsource" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-debugsource-2.61-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcap-debuginfo" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-debuginfo-2.61-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libcap-help" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-help-2.61-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcap-debuginfo" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-debuginfo-2.61-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcap-devel" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-devel-2.61-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcap-debugsource" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-debugsource-2.61-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcap" release="5.oe2203sp1" version="2.61">
                         <filename>libcap-2.61-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1346</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28322" id="CVE-2023-28322" title="CVE-2023-28322" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28321" id="CVE-2023-28321" title="CVE-2023-28321" type="cve"></reference>
          </references>
          <description>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-28322)An improper certificate validation vulnerability exists in curl &lt;v8.1.0 in the way it supports matching of wildcard patterns when listed as &#34;Subject Alternative Name&#34; in TLS server certificates. curl can be built to use its own name matching function for TLS rather than one provided by a TLS library. This private wildcard matching function would match IDN (International Domain Name) hosts incorrectly and could as a result accept patterns that otherwise should mismatch. IDN hostnames are converted to puny code before used for certificate checks. Puny coded names always start with `xn--` and should not be allowed to pattern match, but the wildcard check in curl could still check for `x*`, which would match even though the IDN name most likely contained nothing even resembling an `x`.(CVE-2023-28321)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libcurl-devel" release="17.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="17.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="17.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl" release="17.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl" release="17.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="17.oe2203sp1" version="7.79.1">
                         <filename>curl-help-7.79.1-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="17.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="17.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="17.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="17.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="17.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1350</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34151" id="CVE-2023-34151" title="CVE-2023-34151" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34153" id="CVE-2023-34153" title="CVE-2023-34153" type="cve"></reference>
          </references>
          <description>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-34151)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.(CVE-2023-34153)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="2.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1352</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2985" id="CVE-2023-2985" title="CVE-2023-2985" type="cve"></reference>
          </references>
          <description>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-2985)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-debugsource" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1360</id>
          <title>An update for c-ares is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31130" id="CVE-2023-31130" title="CVE-2023-31130" type="cve"></reference>
          </references>
          <description>c-ares is an asynchronous resolver library. ares_inet_net_pton() is vulnerable to a buffer underflow for certain ipv6 addresses, in particular &#34;0::00:00:00/2&#34; was found to cause an issue.  C-ares only uses this function internally for configuration purposes which would require an administrator to configure such an address via ares_set_sortlist(). However, users may externally use ares_inet_net_pton() for other purposes and thus be vulnerable to more severe issues. This issue has been fixed in 1.19.1.(CVE-2023-31130)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="c-ares-debuginfo" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-devel" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-debugsource" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="c-ares-help" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-help-1.18.1-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-devel" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debuginfo" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debugsource" release="7.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1361</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33288" id="CVE-2023-33288" title="CVE-2023-33288" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48502" id="CVE-2022-48502" title="CVE-2022-48502" type="cve"></reference>
          </references>
          <description>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-33288)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-2022-48502)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1362</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48502" id="CVE-2022-48502" title="CVE-2022-48502" type="cve"></reference>
          </references>
          <description>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-2022-48502)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1363</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0667" id="CVE-2023-0667" title="CVE-2023-0667" type="cve"></reference>
          </references>
          <description>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-0667)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1364</id>
          <title>An update for cpp-httplib is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-25"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26130" id="CVE-2023-26130" title="CVE-2023-26130" type="cve"></reference>
          </references>
          <description>Versions of the package yhirose/cpp-httplib before 0.12.4 are vulnerable to CRLF Injection when untrusted user input is used to set the content-type header in the HTTP .Patch, .Post, .Put and .Delete requests. This can lead to logical errors and other misbehaviors.**Note:** This issue is present due to an incomplete fix for [CVE-2020-11709](https://security.snyk.io/vuln/SNYK-UNMANAGED-YHIROSECPPHTTPLIB-2366507).(CVE-2023-26130)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cpp-httplib" release="1.oe2203sp1" version="0.12.4">
                         <filename>cpp-httplib-0.12.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cpp-httplib" release="1.oe2203sp1" version="0.12.4">
                         <filename>cpp-httplib-0.12.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1366</id>
          <title>An update for postgresql-jdbc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41946" id="CVE-2022-41946" title="CVE-2022-41946" type="cve"></reference>
          </references>
          <description>pgjdbc is an open source postgresql JDBC Driver. In affected versions a prepared statement using either `PreparedStatement.setText(int, InputStream)` or `PreparedStatemet.setBytea(int, InputStream)` will create a temporary file if the InputStream is larger than 2k. This will create a temporary file which is readable by other users on Unix like systems, but not MacOS. On Unix like systems, the system&#39;s temporary directory is shared between all users on that system. Because of this, when files and directories are written into this directory they are, by default, readable by other users on that same system. This vulnerability does not allow other users to overwrite the contents of these directories or files. This is purely an information disclosure vulnerability. Because certain JDK file system APIs were only added in JDK 1.7, this this fix is dependent upon the version of the JDK you are using. Java 1.7 and higher users: this vulnerability is fixed in 4.5.0. Java 1.6 and lower users: no patch is available. If you are unable to patch, or are stuck running on Java 1.6, specifying the java.io.tmpdir system environment variable to a directory that is exclusively owned by the executing user will mitigate this vulnerability.(CVE-2022-41946)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="postgresql-jdbc-help" release="2.oe2203sp1" version="42.4.1">
                         <filename>postgresql-jdbc-help-42.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-jdbc" release="2.oe2203sp1" version="42.4.1">
                         <filename>postgresql-jdbc-42.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-jdbc-javadoc" release="2.oe2203sp1" version="42.4.1">
                         <filename>postgresql-jdbc-javadoc-42.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1367</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-06-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33288" id="CVE-2023-33288" title="CVE-2023-33288" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48502" id="CVE-2022-48502" title="CVE-2022-48502" type="cve"></reference>
          </references>
          <description>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-33288)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-2022-48502)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.36.0.112.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.36.0.112.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1370</id>
          <title>An update for python-tornado is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28370" id="CVE-2023-28370" title="CVE-2023-28370" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-28370)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-tornado" release="2.oe2203sp1" version="6.1">
                         <filename>python3-tornado-6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-tornado-debugsource" release="2.oe2203sp1" version="6.1">
                         <filename>python-tornado-debugsource-6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-tornado-help" release="2.oe2203sp1" version="6.1">
                         <filename>python-tornado-help-6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-tornado-debuginfo" release="2.oe2203sp1" version="6.1">
                         <filename>python-tornado-debuginfo-6.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-debugsource" release="2.oe2203sp1" version="6.1">
                         <filename>python-tornado-debugsource-6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-help" release="2.oe2203sp1" version="6.1">
                         <filename>python-tornado-help-6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-tornado-debuginfo" release="2.oe2203sp1" version="6.1">
                         <filename>python-tornado-debuginfo-6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-tornado" release="2.oe2203sp1" version="6.1">
                         <filename>python3-tornado-6.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1374</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-06-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2952" id="CVE-2023-2952" title="CVE-2023-2952" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0667" id="CVE-2023-0667" title="CVE-2023-0667" type="cve"></reference>
          </references>
          <description>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(CVE-2023-2952)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-0667)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="1.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1375</id>
          <title>An update for dbus is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-06-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34969" id="CVE-2023-34969" title="CVE-2023-34969" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-34969)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="dbus-x11" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-x11-1.12.20-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dbus-libs" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-libs-1.12.20-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dbus" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-1.12.20-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dbus-debugsource" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-debugsource-1.12.20-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dbus-devel" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-devel-1.12.20-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dbus-debuginfo" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-debuginfo-1.12.20-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dbus-daemon" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-daemon-1.12.20-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="dbus-tools" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-tools-1.12.20-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="dbus-common" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-common-1.12.20-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="dbus-help" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-help-1.12.20-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dbus-tools" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-tools-1.12.20-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dbus-debuginfo" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-debuginfo-1.12.20-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dbus-debugsource" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-debugsource-1.12.20-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dbus-x11" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-x11-1.12.20-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dbus" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-1.12.20-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dbus-daemon" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-daemon-1.12.20-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dbus-libs" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-libs-1.12.20-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="dbus-devel" release="9.oe2203sp1" version="1.12.20">
                         <filename>dbus-devel-1.12.20-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1382</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3141" id="CVE-2023-3141" title="CVE-2023-3141" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3268" id="CVE-2023-3268" title="CVE-2023-3268" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35829" id="CVE-2023-35829" title="CVE-2023-35829" type="cve"></reference>
          </references>
          <description>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-3141)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-3268)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-35829)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-devel" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="kernel-debugsource" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.38.0.114.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.38.0.114.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.38.0.114.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1384</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2828" id="CVE-2023-2828" title="CVE-2023-2828" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-2828)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-license-9.16.23-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="18.oe2203sp1" version="9.16.23">
                         <filename>python3-bind-9.16.23-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="18.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1385</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26965" id="CVE-2023-26965" title="CVE-2023-26965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3316" id="CVE-2023-3316" title="CVE-2023-3316" type="cve"></reference>
          </references>
          <description>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-26965)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-3316)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-tools" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-27.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="27.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1386</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29402" id="CVE-2023-29402" title="CVE-2023-29402" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29404" id="CVE-2023-29404" title="CVE-2023-29404" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29405" id="CVE-2023-29405" title="CVE-2023-29405" type="cve"></reference>
          </references>
          <description>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 &#34;go get&#34;, are not affected (modules retrieved using GOPATH-mode, i.e. GO111MODULE=off, may be affected).(CVE-2023-29402)The go command may execute arbitrary code at build time when using cgo. This may occur when running &#34;go get&#34; on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a &#34;#cgo LDFLAGS&#34; directive. The arguments for a number of flags which are non-optional are incorrectly considered optional, allowing disallowed flags to be smuggled through the LDFLAGS sanitization. This affects usage of both the gc and gccgo compilers.(CVE-2023-29404)The go command may execute arbitrary code at build time when using cgo. This may occur when running &#34;go get&#34; on a malicious module, or when running any other command which builds untrusted code. This is can by triggered by linker flags, specified via a &#34;#cgo LDFLAGS&#34; directive. 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.(CVE-2023-29405)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="19.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="19.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="19.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="19.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1387</id>
          <title>An update for qt5-qtbase is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32762" id="CVE-2023-32762" title="CVE-2023-32762" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32763" id="CVE-2023-32763" title="CVE-2023-32763" type="cve"></reference>
          </references>
          <description>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-32762)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-32763)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtbase-private-devel" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-mysql" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debuginfo" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-examples" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-postgresql" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-gui" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debugsource" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-devel" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-odbc" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-static" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qt5-qtbase-common" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-common-5.15.2-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-static" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-odbc" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-examples" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-postgresql" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debugsource" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-mysql" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-devel" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debuginfo" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-gui" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-private-devel" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1388</id>
          <title>An update for iniparser is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33461" id="CVE-2023-33461" title="CVE-2023-33461" type="cve"></reference>
          </references>
          <description>iniparser v4.1 is vulnerable to NULL Pointer Dereference in function iniparser_getlongint which misses check NULL for function iniparser_getstring&#39;s return.(CVE-2023-33461)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iniparser-debugsource" release="5.oe2203sp1" version="4.1">
                         <filename>iniparser-debugsource-4.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iniparser" release="5.oe2203sp1" version="4.1">
                         <filename>iniparser-4.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iniparser-debuginfo" release="5.oe2203sp1" version="4.1">
                         <filename>iniparser-debuginfo-4.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iniparser-debuginfo" release="5.oe2203sp1" version="4.1">
                         <filename>iniparser-debuginfo-4.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iniparser" release="5.oe2203sp1" version="4.1">
                         <filename>iniparser-4.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iniparser-debugsource" release="5.oe2203sp1" version="4.1">
                         <filename>iniparser-debugsource-4.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1389</id>
          <title>An update for perl-HTTP-Tiny is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31486" id="CVE-2023-31486" title="CVE-2023-31486" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-31486)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="perl-HTTP-Tiny" release="2.oe2203sp1" version="0.080">
                         <filename>perl-HTTP-Tiny-0.080-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-HTTP-Tiny-help" release="2.oe2203sp1" version="0.080">
                         <filename>perl-HTTP-Tiny-help-0.080-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1391</id>
          <title>An update for bouncycastle is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33201" id="CVE-2023-33201" title="CVE-2023-33201" type="cve"></reference>
          </references>
          <description>A flaw was found in Bouncy Castle 1.73. This issue targets the fix of LDAP wild cards. Before the fix there was no validation for the X.500 name of any certificate, subject, or issuer, so the presence of a wild card may lead to information disclosure. This could allow a malicious user to obtain unauthorized information via blind LDAP Injection, exploring the environment and enumerating data. The exploit depends on the structure of the target LDAP directory as well as what kind of errors are exposed to the user.(CVE-2023-33201)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="bouncycastle" release="2.oe2203sp1" version="1.67">
                         <filename>bouncycastle-1.67-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1392</id>
          <title>An update for libX11 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3138" id="CVE-2023-3138" title="CVE-2023-3138" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-3138)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libX11-devel" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-devel-1.7.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libX11-debugsource" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-debugsource-1.7.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libX11-debuginfo" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-debuginfo-1.7.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libX11" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-1.7.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libX11-help" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-help-1.7.2-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libX11-devel" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-devel-1.7.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libX11-debugsource" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-debugsource-1.7.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libX11-debuginfo" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-debuginfo-1.7.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libX11" release="6.oe2203sp1" version="1.7.2">
                         <filename>libX11-1.7.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1395</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3006" id="CVE-2023-3006" title="CVE-2023-3006" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31084" id="CVE-2023-31084" title="CVE-2023-31084" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3161" id="CVE-2023-3161" title="CVE-2023-3161" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3212" id="CVE-2023-3212" title="CVE-2023-3212" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34256" id="CVE-2023-34256" title="CVE-2023-34256" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35788" id="CVE-2023-35788" title="CVE-2023-35788" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35823" id="CVE-2023-35823" title="CVE-2023-35823" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35824" id="CVE-2023-35824" title="CVE-2023-35824" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35828" id="CVE-2023-35828" title="CVE-2023-35828" type="cve"></reference>
          </references>
          <description>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&#39;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-3006)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-31084)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-3161)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-3212)** DISPUTED ** 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. NOTE: this is disputed by third parties because the kernel is not intended to defend against attackers with the stated &#34;When modifying the block device while it is mounted by the filesystem&#34; access.(CVE-2023-34256)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-35788)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 dm1105_remove in drivers/media/pci/dm1105/dm1105.c.(CVE-2023-35824)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-35828)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.39.0.116.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.39.0.116.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.39.0.116.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1398</id>
          <title>An update for snappy-java is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34454" id="CVE-2023-34454" title="CVE-2023-34454" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34455" id="CVE-2023-34455" title="CVE-2023-34455" type="cve"></reference>
          </references>
          <description>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.Version 1.1.10.1 contains a patch for this issue.(CVE-2023-34454)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.(CVE-2023-34455)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="snappy-java" release="2.oe2203sp1" version="1.1.2.4">
                         <filename>snappy-java-1.1.2.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="snappy-java-javadoc" release="2.oe2203sp1" version="1.1.2.4">
                         <filename>snappy-java-javadoc-1.1.2.4-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="snappy-java" release="2.oe2203sp1" version="1.1.2.4">
                         <filename>snappy-java-1.1.2.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1399</id>
          <title>An update for librabbitmq is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35789" id="CVE-2023-35789" title="CVE-2023-35789" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-35789)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="librabbitmq-devel" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-devel-0.9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="librabbitmq-help" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-help-0.9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="librabbitmq-debuginfo" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-debuginfo-0.9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="librabbitmq-debugsource" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-debugsource-0.9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="librabbitmq" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-0.9.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librabbitmq-debugsource" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-debugsource-0.9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librabbitmq-devel" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-devel-0.9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librabbitmq-debuginfo" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-debuginfo-0.9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librabbitmq-help" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-help-0.9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librabbitmq" release="9.oe2203sp1" version="0.9.0">
                         <filename>librabbitmq-0.9.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1400</id>
          <title>An update for perl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31486" id="CVE-2023-31486" title="CVE-2023-31486" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-31486)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="4" arch="aarch64" name="perl-debugsource" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-libs" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debuginfo" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-devel" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="noarch" name="perl-help" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-help-5.34.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debugsource" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-devel" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-libs" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debuginfo" release="8.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1402</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25433" id="CVE-2023-25433" title="CVE-2023-25433" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26966" id="CVE-2023-26966" title="CVE-2023-26966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2908" id="CVE-2023-2908" title="CVE-2023-2908" type="cve"></reference>
          </references>
          <description>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-25433)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-26966)A null pointer dereference issue was discovered in Libtiff&#39;s tif_dir.c file. This flaw allows an attacker to pass a crafted TIFF image file to the tiffcp utility, which triggers runtime error, causing an undefined behavior, resulting in an application crash, eventually leading to a denial of service.(CVE-2023-2908)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-tools" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-28.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="28.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1403</id>
          <title>An update for tang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1672" id="CVE-2023-1672" title="CVE-2023-1672" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-1672)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="tang-debuginfo" release="3.oe2203sp1" version="7">
                         <filename>tang-debuginfo-7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tang-debugsource" release="3.oe2203sp1" version="7">
                         <filename>tang-debugsource-7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tang" release="3.oe2203sp1" version="7">
                         <filename>tang-7-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="tang-help" release="3.oe2203sp1" version="7">
                         <filename>tang-help-7-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tang" release="3.oe2203sp1" version="7">
                         <filename>tang-7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tang-debuginfo" release="3.oe2203sp1" version="7">
                         <filename>tang-debuginfo-7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tang-debugsource" release="3.oe2203sp1" version="7">
                         <filename>tang-debugsource-7-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1404</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29403" id="CVE-2023-29403" title="CVE-2023-29403" type="cve"></reference>
          </references>
          <description>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-29403)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="19.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="19.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="19.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="19.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1408</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34474" id="CVE-2023-34474" title="CVE-2023-34474" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34475" id="CVE-2023-34475" title="CVE-2023-34475" type="cve"></reference>
          </references>
          <description>A heap-based buffer overflow issue was discovered in ImageMagick&#39;s ReadTIM2ImageData() function in coders/tim2.c. A local attacker could trick the user in opening specially crafted file, triggering an out-of-bounds read error, allowing an application to crash, resulting in a denial of service.(CVE-2023-34474)A heap use after free issue was discovered in ImageMagick&#39;s ReplaceXmpValue() function in MagickCore/profile.c. An attacker could trick user to open a specially crafted file to convert, triggering an heap-use-after-free write error, allowing an application to crash, resulting in a denial of service.(CVE-2023-34475)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="3.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1410</id>
          <title>An update for cups is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34241" id="CVE-2023-34241" title="CVE-2023-34241" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-34241)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="cups-printerapp" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-lpd" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-libs" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-client" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debuginfo" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-devel" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-ipptool" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debugsource" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-filesystem" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-filesystem-2.4.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-help" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-help-2.4.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-libs" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-client" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-devel" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-printerapp" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-lpd" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-ipptool" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debugsource" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debuginfo" release="8.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1411</id>
          <title>An update for guava20 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2976" id="CVE-2023-2976" title="CVE-2023-2976" type="cve"></reference>
          </references>
          <description>Use of Java&#39;s default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.(CVE-2023-2976)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="guava20-help" release="11.oe2203sp1" version="20.0">
                         <filename>guava20-help-20.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="guava20" release="11.oe2203sp1" version="20.0">
                         <filename>guava20-20.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1412</id>
          <title>An update for guava is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2976" id="CVE-2023-2976" title="CVE-2023-2976" type="cve"></reference>
          </references>
          <description>Use of Java&#39;s default temporary directory for file creation in `FileBackedOutputStream` in Google Guava versions 1.0 to 31.1 on Unix systems and Android Ice Cream Sandwich allows other users and apps on the machine with access to the default Java temporary directory to be able to access the files created by the class.Even though the security vulnerability is fixed in version 32.0.0, we recommend using version 32.0.1 as version 32.0.0 breaks some functionality under Windows.(CVE-2023-2976)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="guava-help" release="6.oe2203sp1" version="25.0">
                         <filename>guava-help-25.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="guava" release="6.oe2203sp1" version="25.0">
                         <filename>guava-25.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="guava-testlib" release="6.oe2203sp1" version="25.0">
                         <filename>guava-testlib-25.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1415</id>
          <title>An update for kubernetes is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3162" id="CVE-2022-3162" title="CVE-2022-3162" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3294" id="CVE-2022-3294" title="CVE-2022-3294" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2431" id="CVE-2023-2431" title="CVE-2023-2431" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2727" id="CVE-2023-2727" title="CVE-2023-2727" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2728" id="CVE-2023-2728" title="CVE-2023-2728" type="cve"></reference>
          </references>
          <description>Users authorized to list or watch one type of namespaced custom resource cluster-wide can read custom resources of a different type in the same API group without authorization. Clusters are impacted by this vulnerability if all of the following are true: 1. There are 2+ CustomResourceDefinitions sharing the same API group 2. Users have cluster-wide list or watch authorization on one of those custom resources. 3. The same users are not authorized to read another custom resource in the same API group.(CVE-2022-3162)Users may have access to secure endpoints in the control plane network. Kubernetes clusters are only affected if an untrusted user can modify Node objects and send proxy requests to them. Kubernetes supports node proxying, which allows clients of kube-apiserver to access endpoints of a Kubelet to establish connections to Pods, retrieve container logs, and more. While Kubernetes already validates the proxying address for Nodes, a bug in kube-apiserver made it possible to bypass this validation. Bypassing this validation could allow authenticated requests destined for Nodes to to the API server&#39;s private network.(CVE-2022-3294)A security issue was discovered in Kubelet that allows pods to bypass the seccomp profile enforcement. Pods that use localhost type for seccomp profile but specify an empty profile field, are affected by this issue. In this scenario, this vulnerability allows the pod to run in unconfined (seccomp disabled) mode. This bug affects Kubelet.(CVE-2023-2431)Users may be able to launch containers using images that are restricted by ImagePolicyWebhook when using ephemeral containers. Kubernetes clusters are only affected if the ImagePolicyWebhook admission plugin is used together with ephemeral containers.(CVE-2023-2727)Users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using ephemeral containers. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the `kubernetes.io/enforce-mountable-secrets` annotation are used together with ephemeral containers.(CVE-2023-2728)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kubernetes" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-1.20.2-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-help" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-help-1.20.2-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-node" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-node-1.20.2-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-client" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-client-1.20.2-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-master" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-master-1.20.2-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-kubeadm" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubeadm-1.20.2-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-kubelet" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubelet-1.20.2-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-client" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-client-1.20.2-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-help" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-help-1.20.2-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-kubeadm" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubeadm-1.20.2-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-1.20.2-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-master" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-master-1.20.2-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-kubelet" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubelet-1.20.2-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-node" release="20.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-node-1.20.2-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1420</id>
          <title>An update for perl-CPAN is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31484" id="CVE-2023-31484" title="CVE-2023-31484" type="cve"></reference>
          </references>
          <description>CPAN.pm before 2.35 does not verify TLS certificates when downloading distributions over HTTPS.(CVE-2023-31484)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="perl-CPAN" release="2.oe2203sp1" version="2.29">
                         <filename>perl-CPAN-2.29-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-CPAN-help" release="2.oe2203sp1" version="2.29">
                         <filename>perl-CPAN-help-2.29-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1421</id>
          <title>An update for texlive-base is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32700" id="CVE-2023-32700" title="CVE-2023-32700" type="cve"></reference>
          </references>
          <description>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-32700)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="texlive-base-debuginfo" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-base-debuginfo-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lcdftypetools" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lcdftypetools-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-vlna" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-vlna-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-patgen" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-patgen-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-axodraw2" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-axodraw2-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dtl" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dtl-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tex4ht" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tex4ht-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ttfutils" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ttfutils-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-uptex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-uptex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-synctex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-synctex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtexu" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bibtexu-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lib" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lib-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvisvgm" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvisvgm-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-musixtnt" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-musixtnt-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-velthuis" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-velthuis-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pdftex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdftex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-base" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-base-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-gregoriotex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-gregoriotex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvidvi" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvidvi-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipos" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvipos-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bibtex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-xdvi" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-xdvi-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtex8" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bibtex8-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-gsftopk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-gsftopk-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-seetexk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-seetexk-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ptex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ptex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-xetex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-xetex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-afm2pl" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-afm2pl-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipdfmx" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvipdfmx-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipng" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvipng-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-detex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-detex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-kpathsea" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-kpathsea-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-omegaware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-omegaware-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-cjkutils" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-cjkutils-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-makeindex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-makeindex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-autosp" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-autosp-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-chktex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-chktex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tie" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tie-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pmx" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pmx-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-luatex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-luatex-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-m-tx" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-m-tx-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lib-devel" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lib-devel-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-aleph" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-aleph-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-mfware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mfware-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-mflua" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mflua-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pdftools" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdftools-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-web" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-web-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-base-debugsource" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-base-debugsource-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ctie" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ctie-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-metapost" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-metapost-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-cweb" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-cweb-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ps2pk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ps2pk-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-fontware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-fontware-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvips" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvips-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvi2tty" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvi2tty-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-metafont" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-metafont-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dviljk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dviljk-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-texware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texware-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvicopy" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvicopy-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pstools" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pstools-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lacheck" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lacheck-20180414-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexdiff" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latexdiff-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dtxgen" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dtxgen-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-accfonts" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-accfonts-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-authorindex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-authorindex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-arara" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-arara-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-jfmutil" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-jfmutil-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-make4ht" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-make4ht-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fontinst" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-fontinst-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexfileversion" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latexfileversion-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cslatex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-cslatex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-checkcites" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-checkcites-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive-en" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texlive-en-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-findhyph" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-findhyph-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdiff" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texdiff-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-epspdf" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-epspdf-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex2nemeth" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latex2nemeth-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-getmap" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-getmap-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-vpe" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-vpe-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ulqda" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ulqda-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-yplan" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-yplan-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-rubik" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-rubik-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dosepsbin" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dosepsbin-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lua2dox" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lua2dox-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mf2pt1" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mf2pt1-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfcrop" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdfcrop-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texfot" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texfot-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-luaotfload" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-luaotfload-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkjobtexmf" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mkjobtexmf-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-epstopdf" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-epstopdf-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-ctanupload" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ctanupload-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-installfont" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-installfont-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-thumbpdf" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-thumbpdf-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texloganalyser" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texloganalyser-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-eplain" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-eplain-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexpand" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latexpand-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-splitindex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-splitindex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-latexindent" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latexindent-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lyluatex" release="34.oe2203sp1" version="svn47584">
                         <filename>texlive-lyluatex-svn47584-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cachepic" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-cachepic-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ebong" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ebong-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lollipop" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lollipop-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fig4latex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-fig4latex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-match_parens" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-match_parens-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fontools" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-fontools-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ltxfileinfo" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ltxfileinfo-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive-scripts" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texlive-scripts-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ptex-fontmaps" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ptex-fontmaps-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pfarrei" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pfarrei-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-l3build" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-l3build-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-srcredact" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-srcredact-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex-papersize" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latex-papersize-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tpic2pdftex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tpic2pdftex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-exceltex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-exceltex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-context" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-context-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-jadetex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-jadetex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-crossrefware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-crossrefware-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mptopdf" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mptopdf-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texosquery" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texosquery-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfjam" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdfjam-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-adhocfilelist" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-adhocfilelist-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pkfix-helper" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pkfix-helper-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive.infra" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texlive.infra-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-oberdiek" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-oberdiek-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-convbkmk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-convbkmk-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdirflatten" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texdirflatten-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pst2pdf" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pst2pdf-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-multibibliography" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-multibibliography-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdflatexpicscale" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdflatexpicscale-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pythontex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pythontex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fragmaster" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-fragmaster-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texcount" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texcount-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-svn-multi" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-svn-multi-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mltex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mltex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dviasm" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dviasm-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-a2ping" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-a2ping-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdoctk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texdoctk-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-wordcount" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-wordcount-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ptex2pdf" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ptex2pdf-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ltximg" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ltximg-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-kotex-utils" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-kotex-utils-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-makedtx" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-makedtx-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkpic" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mkpic-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-checklistings" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-checklistings-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-csplain" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-csplain-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-de-macro" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-de-macro-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lwarp" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lwarp-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pygmentex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pygmentex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfbook2" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdfbook2-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tetex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tetex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pedigree-perl" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pedigree-perl-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-xmltex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-xmltex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkgrkindex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mkgrkindex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex2man" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latex2man-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-petri-nets" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-petri-nets-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texconfig" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texconfig-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pmxchords" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pmxchords-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ctanify" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ctanify-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bibexport" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bibexport-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-diadia" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-diadia-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdoc" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texdoc-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tex4ebook" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tex4ebook-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bib2gls" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bib2gls-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pst-pdf" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pst-pdf-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cyrillic" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-cyrillic-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-typeoutfileinfo" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-typeoutfileinfo-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-purifyeps" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-purifyeps-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdef" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texdef-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pkfix" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pkfix-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dviinfox" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dviinfox-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-amstex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-amstex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-urlbst" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-urlbst-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pax" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pax-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-musixtex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-musixtex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mathspic" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mathspic-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bundledoc" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bundledoc-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex-git-log" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-latex-git-log-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-listbib" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-listbib-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-sty2dtx" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-sty2dtx-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-perltex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-perltex-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texsis" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texsis-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texliveonfly" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texliveonfly-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ctan-o-mat" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ctan-o-mat-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lilyglyphs" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lilyglyphs-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-glyphlist" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-glyphlist-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-listings-ext" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-listings-ext-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfxup" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdfxup-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-glossaries" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-glossaries-20180414-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-aleph" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-aleph-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tex4ht" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tex4ht-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-mflua" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mflua-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-uptex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-uptex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ttfutils" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ttfutils-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-gregoriotex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-gregoriotex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipos" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvipos-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvips" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvips-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvicopy" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvicopy-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base-debugsource" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-base-debugsource-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ptex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ptex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipdfmx" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvipdfmx-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-m-tx" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-m-tx-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-cjkutils" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-cjkutils-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lib" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lib-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-xdvi" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-xdvi-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-metapost" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-metapost-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-gsftopk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-gsftopk-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-chktex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-chktex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lib-devel" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lib-devel-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-musixtnt" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-musixtnt-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base-debuginfo" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-base-debuginfo-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-kpathsea" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-kpathsea-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-texware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-texware-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pdftools" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdftools-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ctie" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ctie-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-omegaware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-omegaware-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pstools" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pstools-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-mfware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-mfware-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lcdftypetools" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lcdftypetools-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pdftex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pdftex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtex8" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bibtex8-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtexu" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bibtexu-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-fontware" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-fontware-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvi2tty" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvi2tty-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-base-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-synctex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-synctex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-bibtex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-afm2pl" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-afm2pl-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-xetex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-xetex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-velthuis" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-velthuis-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvidvi" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvidvi-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tie" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tie-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-axodraw2" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-axodraw2-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-metafont" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-metafont-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-vlna" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-vlna-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvisvgm" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvisvgm-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dviljk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dviljk-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pmx" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-pmx-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-autosp" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-autosp-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-detex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-detex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lacheck" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-lacheck-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ps2pk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-ps2pk-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dtl" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dtl-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-tex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-seetexk" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-seetexk-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-web" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-web-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-luatex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-luatex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-patgen" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-patgen-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-cweb" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-cweb-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipng" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-dvipng-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-makeindex" release="34.oe2203sp1" version="20180414">
                         <filename>texlive-makeindex-20180414-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1422</id>
          <title>An update for syslinux is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-07-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9841" id="CVE-2016-9841" title="CVE-2016-9841" type="cve"></reference>
          </references>
          <description>inffast.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.(CVE-2016-9841)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="syslinux-nonlinux" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-nonlinux-6.04-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-extlinux-nonlinux" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-extlinux-nonlinux-6.04-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-tftpboot" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-tftpboot-6.04-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-devel" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-devel-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-perl" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-perl-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-extlinux" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-extlinux-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debuginfo" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-debuginfo-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debugsource" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-debugsource-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-efi64" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-efi64-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1424</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3389" id="CVE-2023-3389" title="CVE-2023-3389" type="cve"></reference>
          </references>
          <description>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.We recommend upgrading past commit ef7dfac51d8ed961b742218f526bd589f3900a59 (4716c73b188566865bdd79c3a6709696a224ac04 for 5.10 stable and 0e388fce7aec40992eadee654193cad345d62663 for 5.15 stable).(CVE-2023-3389)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.40.0.117.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.40.0.117.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.40.0.117.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1426</id>
          <title>An update for ncurses is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29491" id="CVE-2023-29491" title="CVE-2023-29491" type="cve"></reference>
          </references>
          <description>ncurses 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.(CVE-2023-29491)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ncurses-compat-libs" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-compat-libs-6.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-static" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-static-6.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-devel" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-devel-6.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-debuginfo" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-debuginfo-6.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-debugsource" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-debugsource-6.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-help" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-help-6.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-6.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-libs" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-libs-6.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ncurses-base" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-base-6.3-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-static" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-static-6.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-compat-libs" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-compat-libs-6.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-help" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-help-6.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-libs" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-libs-6.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-devel" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-devel-6.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-debugsource" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-debugsource-6.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-6.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-debuginfo" release="8.oe2203sp1" version="6.3">
                         <filename>ncurses-debuginfo-6.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1427</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36617" id="CVE-2023-36617" title="CVE-2023-36617" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-36617)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby-devel" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="131.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="131.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="131.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="131.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="131.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="131.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="131.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="131.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="131.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="131.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="131.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="131.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="131.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="131.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="131.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="131.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="131.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-131.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="131.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="131.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="131.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="131.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="131.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="131.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-131.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1431</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4304" id="CVE-2022-4304" title="CVE-2022-4304" type="cve"></reference>
          </references>
          <description>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-4304)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="12.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="12.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="12.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="12.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="12.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="12.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="12.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="12.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="12.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="12.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1432</id>
          <title>An update for gnuplot is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-07-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-25969" id="CVE-2020-25969" title="CVE-2020-25969" type="cve"></reference>
          </references>
          <description>gnuplot v5.5 was discovered to contain a buffer overflow via the function plotrequest().(CVE-2020-25969)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnuplot-debugsource" release="14.oe2203sp1" version="5.0.6">
                         <filename>gnuplot-debugsource-5.0.6-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnuplot" release="14.oe2203sp1" version="5.0.6">
                         <filename>gnuplot-5.0.6-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnuplot-debuginfo" release="14.oe2203sp1" version="5.0.6">
                         <filename>gnuplot-debuginfo-5.0.6-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnuplot-help" release="14.oe2203sp1" version="5.0.6">
                         <filename>gnuplot-help-5.0.6-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnuplot-debuginfo" release="14.oe2203sp1" version="5.0.6">
                         <filename>gnuplot-debuginfo-5.0.6-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnuplot" release="14.oe2203sp1" version="5.0.6">
                         <filename>gnuplot-5.0.6-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnuplot-debugsource" release="14.oe2203sp1" version="5.0.6">
                         <filename>gnuplot-debugsource-5.0.6-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1433</id>
          <title>An update for zlib is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-07-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9840" id="CVE-2016-9840" title="CVE-2016-9840" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9842" id="CVE-2016-9842" title="CVE-2016-9842" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-9843" id="CVE-2016-9843" title="CVE-2016-9843" type="cve"></reference>
          </references>
          <description>inftrees.c in zlib 1.2.8 might allow context-dependent attackers to have unspecified impact by leveraging improper pointer arithmetic.(CVE-2016-9840)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-9842)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.(CVE-2016-9843)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="syslinux-tftpboot" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-tftpboot-6.04-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-nonlinux" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-nonlinux-6.04-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-extlinux-nonlinux" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-extlinux-nonlinux-6.04-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debugsource" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-debugsource-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-extlinux" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-extlinux-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debuginfo" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-debuginfo-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-efi64" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-efi64-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-perl" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-perl-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-devel" release="14.oe2203sp1" version="6.04">
                         <filename>syslinux-devel-6.04-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1434</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3576" id="CVE-2023-3576" title="CVE-2023-3576" type="cve"></reference>
          </references>
          <description>A vulnerability was found in libtiff where a memory leak exists in tools/tiffcrop.c.References:https://gitlab.com/libtiff/libtiff/-/merge_requests/475(CVE-2023-3576)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-debugsource" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-tools" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-29.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="29.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1436</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1295" id="CVE-2023-1295" title="CVE-2023-1295" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3090" id="CVE-2023-3090" title="CVE-2023-3090" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3117" id="CVE-2023-3117" title="CVE-2023-3117" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31248" id="CVE-2023-31248" title="CVE-2023-31248" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3220" id="CVE-2023-3220" title="CVE-2023-3220" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3338" id="CVE-2023-3338" title="CVE-2023-3338" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3358" id="CVE-2023-3358" title="CVE-2023-3358" type="cve"></reference>
          </references>
          <description>A time-of-check to time-of-use issue exists in io_uring subsystem&#39;s IORING_OP_CLOSE operation in the Linux kernel&#39;s versions 5.6 - 5.11 (inclusive), which allows a local user to elevate their privileges to root. Introduced in b5dba59e0cf7e2cc4d3b3b1ac5fe81ddf21959eb, patched in 9eac1904d3364254d622bf2c771c4f85cd435fc2, backported to stable in 788d0824269bef539fe31a785b1517882eafed93.(CVE-2023-1295)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.We recommend upgrading past commit 90cbed5247439a966b645b34eb0a2e037836ea8e.(CVE-2023-3090)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-3117)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-31248)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-3220)A flaw null pointer dereference in the Linux kernel DECnet networking protocol was found. A remote user could use this flaw to crash the system.(CVE-2023-3338)A null pointer dereference was found in the Linux kernel&#39;s Integrated Sensor Hub (ISH) driver. This issue could allow a local user to crash the system.(CVE-2023-3358)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-debugsource" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.41.0.119.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-source" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.41.0.119.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.41.0.119.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1440</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36053" id="CVE-2023-36053" title="CVE-2023-36053" type="cve"></reference>
          </references>
          <description>In Django 3.2 before 3.2.20, 4 before 4.1.10, and 4.2 before 4.2.3, EmailValidator and URLValidator are subject to a potential ReDoS (regular expression denial of service) attack via a very large number of domain name labels of emails and URLs.(CVE-2023-36053)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="5.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="5.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-5.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1441</id>
          <title>An update for cjose is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37464" id="CVE-2023-37464" title="CVE-2023-37464" type="cve"></reference>
          </references>
          <description>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).(CVE-2023-37464)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cjose-debuginfo" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-debuginfo-0.6.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cjose" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-0.6.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cjose-devel" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-devel-0.6.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cjose-debugsource" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-debugsource-0.6.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cjose-debuginfo" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-debuginfo-0.6.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cjose" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-0.6.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cjose-devel" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-devel-0.6.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cjose-debugsource" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-debugsource-0.6.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cjose" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-0.6.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cjose-devel" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-devel-0.6.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cjose-debugsource" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-debugsource-0.6.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cjose-debuginfo" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-debuginfo-0.6.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cjose" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-0.6.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cjose-devel" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-devel-0.6.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cjose-debugsource" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-debugsource-0.6.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cjose-debuginfo" release="1.oe2203sp1" version="0.6.2.2">
                         <filename>cjose-debuginfo-0.6.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1442</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3428" id="CVE-2023-3428" title="CVE-2023-3428" type="cve"></reference>
          </references>
          <description>A vulnerability was found in ImageMagick &lt;=7.1.1, where heap-based buffer overflow was found in coders/tiff.c.References:https://github.com/ImageMagick/ImageMagick/commit/a531d28e31309676ce8168c3b6dbbb5374b78790(CVE-2023-3428)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="4.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1443</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-07-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32001" id="CVE-2023-32001" title="CVE-2023-32001" type="cve"></reference>
          </references>
          <description>libcurl can be told to save cookie, HSTS and/or alt-svc data to files. Whendoing this, it called `stat()` followed by `fopen()` in a way that made itvulnerable to a TOCTOU race condition problem.By exploiting this flaw, an attacker could trick the victim to create oroverwrite protected files holding this data in ways it was not intended to.(CVE-2023-32001)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="curl" release="23.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="23.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl-devel" release="23.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="23.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl" release="23.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="23.oe2203sp1" version="7.79.1">
                         <filename>curl-help-7.79.1-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="23.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="23.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="23.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="23.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="23.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1448</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45886" id="CVE-2022-45886" title="CVE-2022-45886" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3390" id="CVE-2023-3390" title="CVE-2023-3390" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35001" id="CVE-2023-35001" title="CVE-2023-35001" type="cve"></reference>
          </references>
          <description>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-2022-45886)A use-after-free vulnerability was found in the Linux kernel&#39;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-2023-3390)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-35001)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.42.0.120.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.42.0.120.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.42.0.120.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1452</id>
          <title>An update for samba is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2127" id="CVE-2022-2127" title="CVE-2022-2127" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3347" id="CVE-2023-3347" title="CVE-2023-3347" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34966" id="CVE-2023-34966" title="CVE-2023-34966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34967" id="CVE-2023-34967" title="CVE-2023-34967" type="cve"></reference>
          </references>
          <description>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-2022-2127)A vulnerability was found in Samba&#39;s SMB2 packet signing mechanism. The SMB2 packet signing is not enforced if an admin configured &#34;server signing = required&#34; or for SMB2 connections to Domain Controllers where SMB2 packet signing is mandatory. This flaw allows an attacker to perform attacks, such as a man-in-the-middle attack, by intercepting the network traffic and modifying the SMB2 messages between client and server, affecting the integrity of the data.(CVE-2023-3347)An infinite loop vulnerability was found in Samba&#39;s mdssvc RPC service for Spotlight. When parsing Spotlight mdssvc RPC packets sent by the client, the core unmarshalling function sl_unpack_loop() did not validate a field in the network packet that contains the count of elements in an array-like structure. By passing 0 as the count value, the attacked function will run in an endless loop consuming 100% CPU. This flaw allows an attacker to issue a malformed RPC request, triggering an infinite loop, resulting in a denial of service condition.(CVE-2023-34966)A Type Confusion vulnerability was found in Samba&#39;s mdssvc RPC service for Spotlight. When parsing Spotlight mdssvc RPC packets, one encoded data structure is a key-value style dictionary where the keys are character strings, and the values can be any of the supported types in the mdssvc protocol. Due to a lack of type checking in callers of the dalloc_value_for_key() function, which returns the object associated with a key, a caller may trigger a crash in talloc_get_size() when talloc detects that the passed-in pointer is not a valid talloc pointer. With an RPC worker process shared among multiple client connections, a malicious client or attacker can trigger a process crash in a shared RPC mdssvc worker process, affecting all other clients this worker serves.(CVE-2023-34967)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="samba-common" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-common-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debugsource" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-debugsource-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-modules" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-modules-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient-devel" release="6.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-devel-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-libs" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-libs-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debuginfo" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-debuginfo-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-client" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-client-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-devel" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-devel-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-bind-dlz" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-bind-dlz-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-dc" release="6.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-dc-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba" release="6.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-clients" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-clients-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-provision" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-provision-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-krb5-printing" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-krb5-printing-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-client-libs" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-client-libs-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-help" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-help-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-test" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-test-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ctdb" release="6.oe2203sp1" version="4.17.5">
                         <filename>ctdb-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common-tools" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-common-tools-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-usershares" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-usershares-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient" release="6.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-test" release="6.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-test-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-libs" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-libs-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-krb5-locator" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-krb5-locator-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient-devel" release="6.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-devel-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient" release="6.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-4.17.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="samba-pidl" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-pidl-4.17.5-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-modules" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-modules-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-dc" release="6.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-dc-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ctdb" release="6.oe2203sp1" version="4.17.5">
                         <filename>ctdb-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-vfs-glusterfs" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-vfs-glusterfs-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient-devel" release="6.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-devel-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-libs" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-libs-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient" release="6.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-libs" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-libs-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba" release="6.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-client" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-client-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-client-libs" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-client-libs-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common-tools" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-common-tools-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-krb5-printing" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-krb5-printing-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-bind-dlz" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-bind-dlz-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient" release="6.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-common-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debugsource" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-debugsource-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-provision" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-provision-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient-devel" release="6.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-devel-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-devel" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-devel-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-usershares" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-usershares-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-clients" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-clients-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-help" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-help-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-test" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-test-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debuginfo" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-debuginfo-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-krb5-locator" release="6.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-krb5-locator-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-test" release="6.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-test-4.17.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1456</id>
          <title>An update for python-reportlab is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-07-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33733" id="CVE-2023-33733" title="CVE-2023-33733" type="cve"></reference>
          </references>
          <description>Reportlab up to v3.6.12 allows attackers to execute arbitrary code via supplying a crafted PDF file.(CVE-2023-33733)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-reportlab" release="2.oe2203sp1" version="3.6.10">
                         <filename>python3-reportlab-3.6.10-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-reportlab-debugsource" release="2.oe2203sp1" version="3.6.10">
                         <filename>python-reportlab-debugsource-3.6.10-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-reportlab-debuginfo" release="2.oe2203sp1" version="3.6.10">
                         <filename>python-reportlab-debuginfo-3.6.10-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-reportlab-help" release="2.oe2203sp1" version="3.6.10">
                         <filename>python-reportlab-help-3.6.10-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-reportlab" release="2.oe2203sp1" version="3.6.10">
                         <filename>python3-reportlab-3.6.10-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-reportlab-debuginfo" release="2.oe2203sp1" version="3.6.10">
                         <filename>python-reportlab-debuginfo-3.6.10-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-reportlab-debugsource" release="2.oe2203sp1" version="3.6.10">
                         <filename>python-reportlab-debugsource-3.6.10-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1457</id>
          <title>An update for python-certifi is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23491" id="CVE-2022-23491" title="CVE-2022-23491" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37920" id="CVE-2023-37920" title="CVE-2023-37920" type="cve"></reference>
          </references>
          <description>Certifi is a curated collection of Root Certificates for validating the trustworthiness of SSL certificates while verifying the identity of TLS hosts. Certifi 2022.12.07 removes root certificates from &#34;TrustCor&#34; from the root store. These are in the process of being removed from Mozilla&#39;s trust store. TrustCor&#39;s root certificates are being removed pursuant to an investigation prompted by media reporting that TrustCor&#39;s ownership also operated a business that produced spyware. Conclusions of Mozilla&#39;s investigation can be found in the linked google group discussion.(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 prior to version 2023.07.22 recognizes &#34;e-Tugra&#34; root certificates. e-Tugra&#39;s root certificates were subject to an investigation prompted by reporting of security issues in their systems. Certifi 2023.07.22 removes root certificates from &#34;e-Tugra&#34; from the root store.(CVE-2023-37920)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-certifi" release="1.oe2203sp1" version="2023.7.22">
                         <filename>python3-certifi-2023.7.22-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-certifi-help" release="1.oe2203sp1" version="2023.7.22">
                         <filename>python-certifi-help-2023.7.22-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1458</id>
          <title>An update for redis is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24834" id="CVE-2022-24834" title="CVE-2022-24834" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-24834)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="redis-debuginfo" release="6.oe2203sp1" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debugsource" release="6.oe2203sp1" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis" release="6.oe2203sp1" version="4.0.14">
                         <filename>redis-4.0.14-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debugsource" release="6.oe2203sp1" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis" release="6.oe2203sp1" version="4.0.14">
                         <filename>redis-4.0.14-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debuginfo" release="6.oe2203sp1" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1462</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-08-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38288" id="CVE-2023-38288" title="CVE-2023-38288" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38289" id="CVE-2023-38289" title="CVE-2023-38289" type="cve"></reference>
          </references>
          <description>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-38288)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.(CVE-2023-38289)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-static" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-tools" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-30.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="30.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1466</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
          </references>
          <description>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 longdelays. Where the key or parameters that are being checked have been obtainedfrom an untrusted source this may lead to a Denial of Service.The function DH_check() performs various checks on DH parameters. One of thosechecks confirms that the modulus (&#39;p&#39; parameter) is not too large. Trying to usea very large modulus is slow and OpenSSL will not normally use a modulus whichis over 10,000 bits in length.However the DH_check() function checks numerous aspects of the key or parametersthat have been supplied. Some of those checks use the supplied modulus valueeven if it has already been found to be too large.An application that calls DH_check() and supplies a key or parameters obtainedfrom 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() andEVP_PKEY_param_check().Also vulnerable are the OpenSSL dhparam and pkeyparam command line applicationswhen using the &#39;-check&#39; 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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="24.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1467</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-08-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21255" id="CVE-2023-21255" title="CVE-2023-21255" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2163" id="CVE-2023-2163" title="CVE-2023-2163" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32248" id="CVE-2023-32248" title="CVE-2023-32248" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32255" id="CVE-2023-32255" title="CVE-2023-32255" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3567" id="CVE-2023-3567" title="CVE-2023-3567" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3609" id="CVE-2023-3609" title="CVE-2023-3609" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3610" id="CVE-2023-3610" title="CVE-2023-3610" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3611" id="CVE-2023-3611" title="CVE-2023-3611" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3776" id="CVE-2023-3776" title="CVE-2023-3776" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38426" id="CVE-2023-38426" title="CVE-2023-38426" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38428" id="CVE-2023-38428" title="CVE-2023-38428" type="cve"></reference>
          </references>
          <description>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-21255)(CVE-2023-2163)A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_TREE_CONNECT and SMB2_QUERY_INFO commands. The issue results from the lack of proper validation of a pointer prior to accessing it. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.(CVE-2023-32248)VUL-0: CVE-2023-32255: kernel: Linux Kernel ksmbd Session Setup Memory Leak Denial-of-Service Vulnerability(CVE-2023-32255)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-3567)A use-after-free vulnerability in the Linux kernel&#39;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-3609)A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation.Flaw in the error handling of bound chains causes a use-after-free in the abort path of NFT_MSG_NEWRULE. The vulnerability requires CAP_NET_ADMIN to be triggered.We recommend upgrading past commit 4bedf9eee016286c835e3d8fa981ddece5338795.(CVE-2023-3610)An out-of-bounds write vulnerability in the Linux kernel&#39;s net/sched: sch_qfq component can be exploited to achieve local privilege escalation.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-3611)A use-after-free vulnerability in the Linux kernel&#39;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-3776)An issue was discovered in the Linux kernel before 6.3.4. ksmbd has an out-of-bounds read in smb2_find_context_vals when create_context&#39;s name_len is larger than the tag length.(CVE-2023-38426)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-38428)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.43.0.121.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-tools-devel" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-source" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.43.0.121.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.43.0.121.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1475</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0664" id="CVE-2023-0664" title="CVE-2023-0664" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2861" id="CVE-2023-2861" title="CVE-2023-2861" type="cve"></reference>
          </references>
          <description>A flaw was found in the QEMU Guest Agent service for Windows. A local unprivileged user may be able to manipulate the QEMU Guest Agent&#39;s Windows installer via repair custom actions to elevate their privileges on the system.(CVE-2023-0664)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.(CVE-2023-2861)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-76.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-76.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="76.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-76.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1478</id>
          <title>An update for python-pygments is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40896" id="CVE-2022-40896" title="CVE-2022-40896" type="cve"></reference>
          </references>
          <description>A ReDoS issue was discovered in pygments/lexers/smithy.py in pygments through 2.15.0 via SmithyLexer.(CVE-2022-40896)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-pygments" release="4.oe2203sp1" version="2.10.0">
                         <filename>python3-pygments-2.10.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-pygments-help" release="4.oe2203sp1" version="2.10.0">
                         <filename>python-pygments-help-2.10.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1480</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38408" id="CVE-2023-38408" title="CVE-2023-38408" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-38408)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openssh-server" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.23.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debuginfo" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-help-8.8p1-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.23.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="23.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1481</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3817" id="CVE-2023-3817" title="CVE-2023-3817" type="cve"></reference>
          </references>
          <description>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 longdelays. Where the key or parameters that are being checked have been obtainedfrom an untrusted source this may lead to a Denial of Service.The function DH_check() performs various checks on DH parameters. After fixingCVE-2023-3446 it was discovered that a large q parameter value can also triggeran overly long computation during some of these checks. A correct q value,if present, cannot be larger than the modulus p parameter, thus it isunnecessary to perform these checks if q is larger than p.An application that calls DH_check() and supplies a key or parameters obtainedfrom 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() andEVP_PKEY_param_check().Also vulnerable are the OpenSSL dhparam and pkeyparam command line applicationswhen using the &#34;-check&#34; 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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="25.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1482</id>
          <title>An update for pcre2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41409" id="CVE-2022-41409" title="CVE-2022-41409" type="cve"></reference>
          </references>
          <description>Integer overflow vulnerability in pcre2test before 10.41 allows attackers to cause a denial of service or other unspecified impacts via negative input.(CVE-2022-41409)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pcre2" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-10.39-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcre2-debuginfo" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-debuginfo-10.39-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcre2-debugsource" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-debugsource-10.39-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcre2-devel" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-devel-10.39-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="pcre2-help" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-help-10.39-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcre2" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-10.39-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcre2-debugsource" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-debugsource-10.39-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcre2-devel" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-devel-10.39-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcre2-debuginfo" release="9.oe2203sp1" version="10.39">
                         <filename>pcre2-debuginfo-10.39-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1485</id>
          <title>An update for sqlite is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36191" id="CVE-2023-36191" title="CVE-2023-36191" type="cve"></reference>
          </references>
          <description>sqlite3 v3.40.1 was discovered to contain a segmentation violation at /sqlite3_aflpp/shell.c.(CVE-2023-36191)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sqlite" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-3.37.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite-debugsource" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debugsource-3.37.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite-debuginfo" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debuginfo-3.37.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite-devel" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-devel-3.37.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sqlite-help" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-help-3.37.2-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-debugsource" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debugsource-3.37.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-debuginfo" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debuginfo-3.37.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-3.37.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-devel" release="6.oe2203sp1" version="3.37.2">
                         <filename>sqlite-devel-3.37.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1488</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3648" id="CVE-2023-3648" title="CVE-2023-3648" type="cve"></reference>
          </references>
          <description>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(CVE-2023-3648)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="2.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1490</id>
          <title>An update for qt5-qtbase is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24607" id="CVE-2023-24607" title="CVE-2023-24607" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-24607)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtbase-static" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-private-devel" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-gui" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-mysql" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-odbc" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debugsource" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debuginfo" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-postgresql" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-examples" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-devel" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qt5-qtbase-common" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-common-5.15.2-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-static" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-examples" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-devel" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-gui" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-postgresql" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-mysql" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debuginfo" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-odbc" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-private-devel" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debugsource" release="7.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1491</id>
          <title>An update for scipy is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25399" id="CVE-2023-25399" title="CVE-2023-25399" type="cve"></reference>
          </references>
          <description>A refcounting issue which leads to potential memory leak was discovered in scipy commit 8627df31ab in Py_FindObjects() function.(CVE-2023-25399)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-scipy" release="2.oe2203sp1" version="1.6.2">
                         <filename>python3-scipy-1.6.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-scipy" release="2.oe2203sp1" version="1.6.2">
                         <filename>python3-scipy-1.6.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1492</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38427" id="CVE-2023-38427" title="CVE-2023-38427" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38429" id="CVE-2023-38429" title="CVE-2023-38429" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38430" id="CVE-2023-38430" title="CVE-2023-38430" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4004" id="CVE-2023-4004" title="CVE-2023-4004" type="cve"></reference>
          </references>
          <description>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-38427)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-38429)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.(CVE-2023-38430)A use-after-free flaw was found in the Linux kernel&#39;s netfilter in the way a user triggers the nft_pipapo_remove function with the element, without a NFT_SET_EXT_KEY_END. This issue could allow a local user to crash the system or potentially escalate their privileges on the system.(CVE-2023-4004)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.44.0.122.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-devel" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.44.0.122.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.44.0.122.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1497</id>
          <title>An update for iperf3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38403" id="CVE-2023-38403" title="CVE-2023-38403" type="cve"></reference>
          </references>
          <description>iperf3 before 3.14 allows peers to cause an integer overflow and heap corruption via a crafted length field.(CVE-2023-38403)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iperf3-debuginfo" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-debuginfo-3.10.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-3.10.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-devel" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-devel-3.10.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-debugsource" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-debugsource-3.10.1-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="iperf3-help" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-help-3.10.1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-debuginfo" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-debuginfo-3.10.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-devel" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-devel-3.10.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-3.10.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-debugsource" release="3.oe2203sp1" version="3.10.1">
                         <filename>iperf3-debugsource-3.10.1-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1498</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29406" id="CVE-2023-29406" title="CVE-2023-29406" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-29406)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="20.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="20.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="20.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="20.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1506</id>
          <title>An update for nghttp2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35945" id="CVE-2023-35945" title="CVE-2023-35945" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-35945)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nghttp2" release="4.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-1.46.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nghttp2-debugsource" release="4.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debugsource-1.46.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnghttp2-devel" release="4.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-devel-1.46.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nghttp2-debuginfo" release="4.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debuginfo-1.46.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnghttp2" release="4.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-1.46.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="nghttp2-help" release="4.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-help-1.46.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2-debuginfo" release="4.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debuginfo-1.46.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2-debugsource" release="4.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debugsource-1.46.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2" release="4.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-1.46.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnghttp2" release="4.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-1.46.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnghttp2-devel" release="4.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-devel-1.46.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1507</id>
          <title>An update for amanda is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30577" id="CVE-2023-30577" title="CVE-2023-30577" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-30577)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="amanda" release="1.oe2203sp1" version="3.5.4">
                         <filename>amanda-3.5.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="amanda-debuginfo" release="1.oe2203sp1" version="3.5.4">
                         <filename>amanda-debuginfo-3.5.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="amanda-debugsource" release="1.oe2203sp1" version="3.5.4">
                         <filename>amanda-debugsource-3.5.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="amanda-help" release="1.oe2203sp1" version="3.5.4">
                         <filename>amanda-help-3.5.4-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="amanda-debuginfo" release="1.oe2203sp1" version="3.5.4">
                         <filename>amanda-debuginfo-3.5.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="amanda-debugsource" release="1.oe2203sp1" version="3.5.4">
                         <filename>amanda-debugsource-3.5.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="amanda" release="1.oe2203sp1" version="3.5.4">
                         <filename>amanda-3.5.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1508</id>
          <title>An update for yasm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37732" id="CVE-2023-37732" title="CVE-2023-37732" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-37732)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="yasm" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-1.3.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-debuginfo" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-debuginfo-1.3.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-devel" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-devel-1.3.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-debugsource" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-debugsource-1.3.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="yasm-help" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-help-1.3.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-1.3.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-devel" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-devel-1.3.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-debuginfo" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-debuginfo-1.3.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-debugsource" release="11.oe2203sp1" version="1.3.0">
                         <filename>yasm-debugsource-1.3.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1512</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3772" id="CVE-2023-3772" title="CVE-2023-3772" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3863" id="CVE-2023-3863" title="CVE-2023-3863" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4133" id="CVE-2023-4133" title="CVE-2023-4133" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4147" id="CVE-2023-4147" title="CVE-2023-4147" type="cve"></reference>
          </references>
          <description>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-3772)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-3863)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-4133)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-4147)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.45.0.123.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.45.0.123.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.45.0.123.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1514</id>
          <title>An update for procps-ng is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4016" id="CVE-2023-4016" title="CVE-2023-4016" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-4016)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="procps-ng" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-4.0.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="procps-ng-debugsource" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-debugsource-4.0.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="procps-ng-debuginfo" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-debuginfo-4.0.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="procps-ng-devel" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-devel-4.0.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="procps-ng-i18n" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-i18n-4.0.2-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="procps-ng-help" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-help-4.0.2-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="procps-ng-debuginfo" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-debuginfo-4.0.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="procps-ng-devel" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-devel-4.0.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="procps-ng" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-4.0.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="procps-ng-debugsource" release="10.oe2203sp1" version="4.0.2">
                         <filename>procps-ng-debugsource-4.0.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1515</id>
          <title>An update for python-werkzeug is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23934" id="CVE-2023-23934" title="CVE-2023-23934" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25577" id="CVE-2023-25577" title="CVE-2023-25577" type="cve"></reference>
          </references>
          <description>Werkzeug is a comprehensive WSGI web application library. Browsers may allow &#34;nameless&#34; cookies that look like `=value` instead of `key=value`. A vulnerable browser may allow a compromised application on an adjacent subdomain to exploit this to set a cookie like `=__Host-test=bad` for another subdomain. Werkzeug prior to 2.2.3 will parse the cookie `=__Host-test=bad` as __Host-test=bad`. If a Werkzeug application is running next to a vulnerable or malicious subdomain which sets such a cookie using a vulnerable browser, the Werkzeug application will see the bad cookie value but the valid cookie key. The issue is fixed in Werkzeug 2.2.3.(CVE-2023-23934)Werkzeug is a comprehensive WSGI web application library. Prior to version 2.2.3, Werkzeug&#39;s multipart form data parser will parse an unlimited number of parts, including file parts. Parts can be a small amount of bytes, but each requires CPU time to parse and may use more memory as Python data. If a request can be made to an endpoint that accesses `request.data`, `request.form`, `request.files`, or `request.get_data(parse_form_data=False)`, it can cause unexpectedly high resource usage. This allows an attacker to cause a denial of service by sending crafted multipart data to an endpoint that will parse it. The amount of CPU time required can block worker processes from handling legitimate requests. The amount of RAM required can trigger an out of memory kill of the process. Unlimited file parts can use up memory and file handles. If many concurrent requests are sent continuously, this can exhaust or kill all available workers. Version 2.2.3 contains a patch for this issue.(CVE-2023-25577)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-werkzeug-help" release="4.oe2203sp1" version="2.0.3">
                         <filename>python-werkzeug-help-2.0.3-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-werkzeug" release="4.oe2203sp1" version="2.0.3">
                         <filename>python3-werkzeug-2.0.3-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1519</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2007-4559" id="CVE-2007-4559" title="CVE-2007-4559" type="cve"></reference>
          </references>
          <description>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.(CVE-2007-4559)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-debugsource" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-help-3.9.9-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="25.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1524</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3180" id="CVE-2023-3180" title="CVE-2023-3180" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3301" id="CVE-2023-3301" title="CVE-2023-3301" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-3180)The async nature of the hot-unplug enables an easy to reproduce race scenario where the net device backend is cleared before the virtio-net pci frontend has been unplugged (or the ACPI unplug has been acked by the guest?). The guest can use this time window to, at least, trigger an assertion.(CVE-2023-3301)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-78.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-78.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="78.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-78.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1529</id>
          <title>An update for python-GitPython is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-08-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24439" id="CVE-2022-24439" title="CVE-2022-24439" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40267" id="CVE-2023-40267" title="CVE-2023-40267" type="cve"></reference>
          </references>
          <description>All versions of package gitpython are vulnerable to Remote Code Execution (RCE) due to improper user input validation, which makes it possible to inject a maliciously crafted remote URL into the clone command. Exploiting this vulnerability is possible because the library makes external calls to git without sufficient sanitization of input arguments.(CVE-2022-24439)GitPython before 3.1.32 does not block insecure non-multi options in clone and clone_from. NOTE: this issue exists because of an incomplete fix for CVE-2022-24439.(CVE-2023-40267)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-GitPython-help" release="1.oe2203sp1" version="3.1.32">
                         <filename>python-GitPython-help-3.1.32-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-GitPython" release="1.oe2203sp1" version="3.1.32">
                         <filename>python3-GitPython-3.1.32-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1534</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-08-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3618" id="CVE-2023-3618" title="CVE-2023-3618" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-3618)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-tools" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-31.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="31.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1539</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2860" id="CVE-2023-2860" title="CVE-2023-2860" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4128" id="CVE-2023-4128" title="CVE-2023-4128" type="cve"></reference>
          </references>
          <description>An out-of-bounds read vulnerability was found in the SR-IPv6 implementation in the Linux kernel. The flaw exists within the processing of seg6 attributes. The issue results from the improper validation of user-supplied data, which can result in a read past the end of an allocated buffer. This flaw allows a privileged local user to disclose sensitive information on affected installations of the Linux kernel.(CVE-2023-2860)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-4128)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.46.0.124.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-debugsource" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.46.0.124.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.46.0.124.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1541</id>
          <title>An update for haproxy is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40225" id="CVE-2023-40225" title="CVE-2023-40225" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-40225)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="haproxy" release="4.oe2203sp1" version="2.6.6">
                         <filename>haproxy-2.6.6-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debugsource" release="4.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debuginfo" release="4.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="haproxy-help" release="4.oe2203sp1" version="2.6.6">
                         <filename>haproxy-help-2.6.6-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debugsource" release="4.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy" release="4.oe2203sp1" version="2.6.6">
                         <filename>haproxy-2.6.6-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debuginfo" release="4.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1542</id>
          <title>An update for qpdf is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-08-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-25786" id="CVE-2021-25786" title="CVE-2021-25786" type="cve"></reference>
          </references>
          <description>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.(CVE-2021-25786)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qpdf-debuginfo" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-debuginfo-8.4.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-8.4.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf-devel" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-devel-8.4.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf-debugsource" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-debugsource-8.4.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qpdf-help" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-help-8.4.2-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-debugsource" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-debugsource-8.4.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-8.4.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-debuginfo" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-debuginfo-8.4.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-devel" release="4.oe2203sp1" version="8.4.2">
                         <filename>qpdf-devel-8.4.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1551</id>
          <title>An update for nodejs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-25881" id="CVE-2022-25881" title="CVE-2022-25881" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32212" id="CVE-2022-32212" title="CVE-2022-32212" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32213" id="CVE-2022-32213" title="CVE-2022-32213" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32214" id="CVE-2022-32214" title="CVE-2022-32214" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32215" id="CVE-2022-32215" title="CVE-2022-32215" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-35256" id="CVE-2022-35256" title="CVE-2022-35256" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23918" id="CVE-2023-23918" title="CVE-2023-23918" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23920" id="CVE-2023-23920" title="CVE-2023-23920" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30581" id="CVE-2023-30581" title="CVE-2023-30581" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30589" id="CVE-2023-30589" title="CVE-2023-30589" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30590" id="CVE-2023-30590" title="CVE-2023-30590" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32002" id="CVE-2023-32002" title="CVE-2023-32002" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32006" id="CVE-2023-32006" title="CVE-2023-32006" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32559" id="CVE-2023-32559" title="CVE-2023-32559" type="cve"></reference>
          </references>
          <description>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-25881)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-32212)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-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 strictly use the CRLF sequence to delimit HTTP requests. This 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 correctly handle multi-line Transfer-Encoding headers. This can lead to HTTP Request Smuggling (HRS).(CVE-2022-32215)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-2022-35256)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-23918)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-23920)The use of proto in process.mainModule.proto.require() can bypass the policy mechanism and require modules outside of the policy.json definition.References:https://nodejs.org/en/blog/vulnerability/june-2023-security-releases(CVE-2023-30581)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-30589)The 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.References:https://nodejs.org/en/blog/vulnerability/june-2023-security-releases(CVE-2023-30590)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-32002)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-32006)A privilege escalation vulnerability exists in the experimental policy mechanism in all active release lines: 16.x, 18.x and, 20.x. The use of the deprecated API `process.binding()` can bypass the policy mechanism by requiring internal modules and eventually take advantage of `process.binding(&#39;spawn_sync&#39;)` run arbitrary code, outside of the limits defined in a `policy.json` file. Please note that at the time this CVE was issued, the policy is an experimental feature of Node.js.(CVE-2023-32559)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="npm" release="1.12.22.11.5.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-full-i18n" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-libs" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="v8-devel" release="1.12.22.11.5.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-devel" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debuginfo" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debugsource" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nodejs-docs" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-docs-12.22.11-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="v8-devel" release="1.12.22.11.5.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-libs" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debuginfo" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="npm" release="1.12.22.11.5.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-full-i18n" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-devel" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debugsource" release="5.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1552</id>
          <title>An update for indent is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40305" id="CVE-2023-40305" title="CVE-2023-40305" type="cve"></reference>
          </references>
          <description>GNU indent 2.2.13 has a heap-based buffer overflow in search_brace in indent.c via a crafted file.(CVE-2023-40305)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="indent-debugsource" release="29.oe2203sp1" version="2.2.11">
                         <filename>indent-debugsource-2.2.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="indent-debuginfo" release="29.oe2203sp1" version="2.2.11">
                         <filename>indent-debuginfo-2.2.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="indent" release="29.oe2203sp1" version="2.2.11">
                         <filename>indent-2.2.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="indent-help" release="29.oe2203sp1" version="2.2.11">
                         <filename>indent-help-2.2.11-29.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="indent-debugsource" release="29.oe2203sp1" version="2.2.11">
                         <filename>indent-debugsource-2.2.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="indent" release="29.oe2203sp1" version="2.2.11">
                         <filename>indent-2.2.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="indent-debuginfo" release="29.oe2203sp1" version="2.2.11">
                         <filename>indent-debuginfo-2.2.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1553</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-33196" id="CVE-2022-33196" title="CVE-2022-33196" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38090" id="CVE-2022-38090" title="CVE-2022-38090" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40982" id="CVE-2022-40982" title="CVE-2022-40982" type="cve"></reference>
          </references>
          <description>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-33196)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-38090)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-40982)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="41.oe2203sp1" version="2.1">
                         <filename>microcode_ctl-2.1-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1555</id>
          <title>An update for krb5 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36054" id="CVE-2023-36054" title="CVE-2023-36054" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-36054)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="krb5-server" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-server-1.19.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-debugsource" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-debugsource-1.19.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-debuginfo" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-debuginfo-1.19.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-1.19.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-devel" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-devel-1.19.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-libs" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-libs-1.19.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-client" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-client-1.19.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="krb5-help" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-help-1.19.2-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-1.19.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-debuginfo" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-debuginfo-1.19.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-debugsource" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-debugsource-1.19.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-client" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-client-1.19.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-devel" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-devel-1.19.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-libs" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-libs-1.19.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-server" release="9.oe2203sp1" version="1.19.2">
                         <filename>krb5-server-1.19.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1560</id>
          <title>An update for clamav is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20197" id="CVE-2023-20197" title="CVE-2023-20197" type="cve"></reference>
          </references>
          <description>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 .(CVE-2023-20197)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="clamav-update" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-update-0.103.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-milter" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-milter-0.103.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-debugsource" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-debugsource-0.103.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-devel" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-devel-0.103.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-help" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-help-0.103.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamd" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamd-0.103.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-debuginfo" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-debuginfo-0.103.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-0.103.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-data" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-data-0.103.9-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-filesystem" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-filesystem-0.103.9-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-devel" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-devel-0.103.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-debugsource" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-debugsource-0.103.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-help" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-help-0.103.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamd" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamd-0.103.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-milter" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-milter-0.103.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-update" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-update-0.103.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-0.103.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-debuginfo" release="1.oe2203sp1" version="0.103.9">
                         <filename>clamav-debuginfo-0.103.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1561</id>
          <title>An update for poppler is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-23804" id="CVE-2020-23804" title="CVE-2020-23804" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37050" id="CVE-2022-37050" title="CVE-2022-37050" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37051" id="CVE-2022-37051" title="CVE-2022-37051" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37052" id="CVE-2022-37052" title="CVE-2022-37052" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38349" id="CVE-2022-38349" title="CVE-2022-38349" type="cve"></reference>
          </references>
          <description>Uncontrolled Recursion in pdfinfo, and pdftops in poppler 0.89.0 allows remote attackers to cause a denial of service via crafted input.(CVE-2020-23804)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-37050)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-37051)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-37052)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.(CVE-2022-38349)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="poppler" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debuginfo" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debugsource" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-devel" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-devel-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib-devel" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-utils" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-utils-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp-devel" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5-devel" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-glib-doc" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-doc-0.90.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-help" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-help-0.90.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debuginfo" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5-devel" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib-devel" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-devel" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-devel-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debugsource" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-utils" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-utils-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp-devel" release="6.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1562</id>
          <title>An update for flac is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-22219" id="CVE-2020-22219" title="CVE-2020-22219" type="cve"></reference>
          </references>
          <description>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.(CVE-2020-22219)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xmms-flac" release="2.oe2203sp1" version="1.3.4">
                         <filename>xmms-flac-1.3.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flac-debuginfo" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-debuginfo-1.3.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flac-help" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-help-1.3.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flac" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-1.3.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flac-devel" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-devel-1.3.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flac-debugsource" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-debugsource-1.3.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmms-flac" release="2.oe2203sp1" version="1.3.4">
                         <filename>xmms-flac-1.3.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flac-debuginfo" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-debuginfo-1.3.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flac" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-1.3.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flac-help" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-help-1.3.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flac-devel" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-devel-1.3.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flac-debugsource" release="2.oe2203sp1" version="1.3.4">
                         <filename>flac-debugsource-1.3.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1564</id>
          <title>An update for perl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48522" id="CVE-2022-48522" title="CVE-2022-48522" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-48522)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="4" arch="aarch64" name="perl-debugsource" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-libs" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debuginfo" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-devel" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="noarch" name="perl-help" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-help-5.34.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-libs" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-devel" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debuginfo" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debugsource" release="9.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1567</id>
          <title>An update for libpq is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21469" id="CVE-2020-21469" title="CVE-2020-21469" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2454" id="CVE-2023-2454" title="CVE-2023-2454" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2455" id="CVE-2023-2455" title="CVE-2023-2455" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39417" id="CVE-2023-39417" title="CVE-2023-39417" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39418" id="CVE-2023-39418" title="CVE-2023-39418" type="cve"></reference>
          </references>
          <description>** DISPUTED ** 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-2020-21469)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-2454)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-2455)IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, &#39;&#39;, or &#34;&#34;). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.(CVE-2023-39417)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.(CVE-2023-39418)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libpq-debugsource" release="1.oe2203sp1" version="13.12">
                         <filename>libpq-debugsource-13.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq" release="1.oe2203sp1" version="13.12">
                         <filename>libpq-13.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-debuginfo" release="1.oe2203sp1" version="13.12">
                         <filename>libpq-debuginfo-13.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libpq-devel" release="1.oe2203sp1" version="13.12">
                         <filename>libpq-devel-13.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq" release="1.oe2203sp1" version="13.12">
                         <filename>libpq-13.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-debugsource" release="1.oe2203sp1" version="13.12">
                         <filename>libpq-debugsource-13.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-debuginfo" release="1.oe2203sp1" version="13.12">
                         <filename>libpq-debuginfo-13.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libpq-devel" release="1.oe2203sp1" version="13.12">
                         <filename>libpq-devel-13.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1570</id>
          <title>An update for binutils is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46174" id="CVE-2021-46174" title="CVE-2021-46174" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47008" id="CVE-2022-47008" title="CVE-2022-47008" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47011" id="CVE-2022-47011" title="CVE-2022-47011" type="cve"></reference>
          </references>
          <description>Heap-based Buffer Overflow in function bfd_getl32 in Binutils objdump 3.37.(CVE-2021-46174)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.(CVE-2022-47008)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-47011)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="binutils-debuginfo" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-debuginfo-2.37-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-2.37-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-debugsource" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-debugsource-2.37-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-devel" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-devel-2.37-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-help" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-help-2.37-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-help" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-help-2.37-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-debugsource" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-debugsource-2.37-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-debuginfo" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-debuginfo-2.37-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-2.37-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-devel" release="19.oe2203sp1" version="2.37">
                         <filename>binutils-devel-2.37-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1574</id>
          <title>An update for file is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48554" id="CVE-2022-48554" title="CVE-2022-48554" type="cve"></reference>
          </references>
          <description>File before 5.43 has an stack-based buffer over-read in file_copystr in funcs.c. NOTE: &#34;File&#34; is the name of an Open Source project.(CVE-2022-48554)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="file-debuginfo" release="3.oe2203sp1" version="5.41">
                         <filename>file-debuginfo-5.41-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="file-libs" release="3.oe2203sp1" version="5.41">
                         <filename>file-libs-5.41-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="file-help" release="3.oe2203sp1" version="5.41">
                         <filename>file-help-5.41-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="file-devel" release="3.oe2203sp1" version="5.41">
                         <filename>file-devel-5.41-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="file-debugsource" release="3.oe2203sp1" version="5.41">
                         <filename>file-debugsource-5.41-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="file" release="3.oe2203sp1" version="5.41">
                         <filename>file-5.41-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-magic" release="3.oe2203sp1" version="5.41">
                         <filename>python3-magic-5.41-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="file-libs" release="3.oe2203sp1" version="5.41">
                         <filename>file-libs-5.41-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="file-debugsource" release="3.oe2203sp1" version="5.41">
                         <filename>file-debugsource-5.41-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="file-devel" release="3.oe2203sp1" version="5.41">
                         <filename>file-devel-5.41-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="file-debuginfo" release="3.oe2203sp1" version="5.41">
                         <filename>file-debuginfo-5.41-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="file-help" release="3.oe2203sp1" version="5.41">
                         <filename>file-help-5.41-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="file" release="3.oe2203sp1" version="5.41">
                         <filename>file-5.41-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1575</id>
          <title>An update for gawk is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4156" id="CVE-2023-4156" title="CVE-2023-4156" type="cve"></reference>
          </references>
          <description>A heap out of bound read issue exists in builtin.c of gawk prior to version 5.1.1. The array &#34;the_args&#34; takes an unsafe index &#34;val&#34;, 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.https://mail.gnu.org/archive/html/bug-gawk/2022-08/msg00000.htmlhttps://mail.gnu.org/archive/html/bug-gawk/2022-08/msg00023.htmlhttps://fossies.org/linux/gawk/ChangeLog#470 (Line: 470-475)(CVE-2023-4156)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gawk-lang" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-lang-5.1.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gawk-devel" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-devel-5.1.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gawk" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-5.1.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gawk-debuginfo" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-debuginfo-5.1.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gawk-debugsource" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-debugsource-5.1.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gawk-help" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-help-5.1.1-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gawk" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-5.1.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gawk-devel" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-devel-5.1.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gawk-lang" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-lang-5.1.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gawk-debugsource" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-debugsource-5.1.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gawk-debuginfo" release="5.oe2203sp1" version="5.1.1">
                         <filename>gawk-debuginfo-5.1.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1577</id>
          <title>An update for postgresql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39417" id="CVE-2023-39417" title="CVE-2023-39417" type="cve"></reference>
          </references>
          <description>IN THE EXTENSION SCRIPT, a SQL Injection vulnerability was found in PostgreSQL if it uses @extowner@, @extschema@, or @extschema:...@ inside a quoting construct (dollar quoting, &#39;&#39;, or &#34;&#34;). If an administrator has installed files of a vulnerable, trusted, non-bundled extension, an attacker with database-level CREATE privilege can execute arbitrary code as the bootstrap superuser.(CVE-2023-39417)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="postgresql-static" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-static-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debuginfo" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-debuginfo-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plperl" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-plperl-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plpython3" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-plpython3-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-docs" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-docs-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-devel" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-private-devel-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-server-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-llvmjit" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-llvmjit-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-libs" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-private-libs-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debugsource" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-debugsource-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-pltcl" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-pltcl-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server-devel" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-server-devel-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-test" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-test-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-contrib" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-contrib-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-13.12-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-test-rpm-macros" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-test-rpm-macros-13.12-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-contrib" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-contrib-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-libs" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-private-libs-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debuginfo" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-debuginfo-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-static" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-static-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-pltcl" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-pltcl-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-test" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-test-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-docs" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-docs-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-llvmjit" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-llvmjit-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-devel" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-private-devel-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plperl" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-plperl-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-server-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server-devel" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-server-devel-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plpython3" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-plpython3-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debugsource" release="2.oe2203sp1" version="13.12">
                         <filename>postgresql-debugsource-13.12-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1579</id>
          <title>An update for qt is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32573" id="CVE-2023-32573" title="CVE-2023-32573" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-32573)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="qt" release="53.oe2203sp1" version="4.8.7">
                         <filename>qt-4.8.7-53.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt-debugsource" release="53.oe2203sp1" version="4.8.7">
                         <filename>qt-debugsource-4.8.7-53.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt-devel" release="53.oe2203sp1" version="4.8.7">
                         <filename>qt-devel-4.8.7-53.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt-debuginfo" release="53.oe2203sp1" version="4.8.7">
                         <filename>qt-debuginfo-4.8.7-53.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-debugsource" release="53.oe2203sp1" version="4.8.7">
                         <filename>qt-debugsource-4.8.7-53.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-devel" release="53.oe2203sp1" version="4.8.7">
                         <filename>qt-devel-4.8.7-53.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt" release="53.oe2203sp1" version="4.8.7">
                         <filename>qt-4.8.7-53.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-debuginfo" release="53.oe2203sp1" version="4.8.7">
                         <filename>qt-debuginfo-4.8.7-53.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1581</id>
          <title>An update for libreswan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38710" id="CVE-2023-38710" title="CVE-2023-38710" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38711" id="CVE-2023-38711" title="CVE-2023-38711" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38712" id="CVE-2023-38712" title="CVE-2023-38712" type="cve"></reference>
          </references>
          <description>An issue was discovered in Libreswan before 4.12. When an IKEv2 Child SA REKEY packet contains an invalid IPsec protocol ID number of 0 or 1, an error notify INVALID_SPI is sent back. The notify payload&#39;s protocol ID is copied from the incoming packet, but the code that verifies outgoing packets fails an assertion that the protocol ID must be ESP (2) or AH(3) and causes the pluto daemon to crash and restart. NOTE: the earliest affected version is 3.20.(CVE-2023-38710)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-38711)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.(CVE-2023-38712)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libreswan-help" release="1.oe2203sp1" version="4.12">
                         <filename>libreswan-help-4.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan" release="1.oe2203sp1" version="4.12">
                         <filename>libreswan-4.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debuginfo" release="1.oe2203sp1" version="4.12">
                         <filename>libreswan-debuginfo-4.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debugsource" release="1.oe2203sp1" version="4.12">
                         <filename>libreswan-debugsource-4.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-help" release="1.oe2203sp1" version="4.12">
                         <filename>libreswan-help-4.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debuginfo" release="1.oe2203sp1" version="4.12">
                         <filename>libreswan-debuginfo-4.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debugsource" release="1.oe2203sp1" version="4.12">
                         <filename>libreswan-debugsource-4.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan" release="1.oe2203sp1" version="4.12">
                         <filename>libreswan-4.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1582</id>
          <title>An update for librsvg2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38633" id="CVE-2023-38633" title="CVE-2023-38633" type="cve"></reference>
          </references>
          <description>A directory traversal problem in the URL decoder of librsvg before 2.56.3 could be used by local or remote attackers to disclose files (on the local filesystem outside of the expected area), as demonstrated by href=&#34;.?../../../../../../../../../../etc/passwd&#34; in an xi:include element.(CVE-2023-38633)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="librsvg2-debuginfo" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-debuginfo-2.50.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="librsvg2-tools" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-tools-2.50.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="librsvg2" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-2.50.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="librsvg2-devel" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-devel-2.50.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="librsvg2-debugsource" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-debugsource-2.50.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="librsvg2-help" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-help-2.50.5-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librsvg2-devel" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-devel-2.50.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librsvg2" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-2.50.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librsvg2-debugsource" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-debugsource-2.50.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librsvg2-tools" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-tools-2.50.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="librsvg2-debuginfo" release="6.oe2203sp1" version="2.50.5">
                         <filename>librsvg2-debuginfo-2.50.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1583</id>
          <title>An update for busybox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48174" id="CVE-2022-48174" title="CVE-2022-48174" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-48174)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="busybox" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-1.34.1-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-petitboot" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-petitboot-1.34.1-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-help" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-help-1.34.1-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-debugsource" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-debugsource-1.34.1-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-debuginfo" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-debuginfo-1.34.1-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-debugsource" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-debugsource-1.34.1-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-help" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-help-1.34.1-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-debuginfo" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-debuginfo-1.34.1-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-1.34.1-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-petitboot" release="19.oe2203sp1" version="1.34.1">
                         <filename>busybox-petitboot-1.34.1-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1586</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1206" id="CVE-2023-1206" title="CVE-2023-1206" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34319" id="CVE-2023-34319" title="CVE-2023-34319" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38432" id="CVE-2023-38432" title="CVE-2023-38432" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3867" id="CVE-2023-3867" title="CVE-2023-3867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40283" id="CVE-2023-40283" title="CVE-2023-40283" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4194" id="CVE-2023-4194" title="CVE-2023-4194" type="cve"></reference>
          </references>
          <description>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-1206)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-34319)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-38432)(CVE-2023-3867)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-40283)A flaw was found in the Linux kernel&#39;s TUN/TAP functionality. This issue could allow a local user to bypass network filters and gain unauthorized access to some resources. The original patches fixing CVE-2023-1076 are incorrect or incomplete. The problem is that the following upstream commits - a096ccca6e50 (&#34;tun: tun_chr_open(): correctly initialize socket uid&#34;), - 66b2c338adce (&#34;tap: tap_open(): correctly initialize socket uid&#34;), pass &#34;inode-&gt;i_uid&#34; to sock_init_data_uid() as the last parameter and that turns out to not be accurate.(CVE-2023-4194)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.47.0.125.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.47.0.125.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.47.0.125.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1589</id>
          <title>An update for hwloc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47022" id="CVE-2022-47022" title="CVE-2022-47022" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-47022)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hwloc-devel" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-devel-2.7.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hwloc" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-2.7.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hwloc-debugsource" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-debugsource-2.7.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hwloc-debuginfo" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-debuginfo-2.7.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hwloc-help" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-help-2.7.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hwloc-help" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-help-2.7.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hwloc-devel" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-devel-2.7.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hwloc-debuginfo" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-debuginfo-2.7.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hwloc" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-2.7.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hwloc-debugsource" release="2.oe2203sp1" version="2.7.1">
                         <filename>hwloc-debugsource-2.7.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1591</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29409" id="CVE-2023-29409" title="CVE-2023-29409" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-29409)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="22.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="22.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="22.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="22.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1593</id>
          <title>An update for binutils is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4285" id="CVE-2022-4285" title="CVE-2022-4285" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48064" id="CVE-2022-48064" title="CVE-2022-48064" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1972" id="CVE-2023-1972" title="CVE-2023-1972" type="cve"></reference>
          </references>
          <description>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-4285)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-48064)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-2023-1972)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="binutils" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-2.37-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-debuginfo" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-debuginfo-2.37-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-help" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-help-2.37-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-debugsource" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-debugsource-2.37-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="binutils-devel" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-devel-2.37-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-devel" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-devel-2.37-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-2.37-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-help" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-help-2.37-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-debugsource" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-debugsource-2.37-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="binutils-debuginfo" release="23.oe2203sp1" version="2.37">
                         <filename>binutils-debuginfo-2.37-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1599</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40090" id="CVE-2022-40090" title="CVE-2022-40090" type="cve"></reference>
          </references>
          <description>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-2022-40090)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-tools" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="32.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1602</id>
          <title>An update for openjdk-latest is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21549" id="CVE-2022-21549" title="CVE-2022-21549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21830" id="CVE-2023-21830" title="CVE-2023-21830" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21835" id="CVE-2023-21835" title="CVE-2023-21835" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21937" id="CVE-2023-21937" title="CVE-2023-21937" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22006" id="CVE-2023-22006" title="CVE-2023-22006" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22041" id="CVE-2023-22041" title="CVE-2023-22041" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"></reference>
          </references>
          <description>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-21549)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-2022-40433)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-21830)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-21835)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-21843)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-21930)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-21937)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-21938)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-21939)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-21954)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-21967)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-21968)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-22006)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). CVSS 3.1 Base Score 5.1 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).(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, 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. CVSS 3.1 Base Score 3.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2023-22045)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-javadoc" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-javadoc-20.0.2.9-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-devel" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-devel-20.0.2.9-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-headless" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-headless-20.0.2.9-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-src" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-src-20.0.2.9-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-jmods" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-jmods-20.0.2.9-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-javadoc-zip" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-javadoc-zip-20.0.2.9-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-20.0.2.9-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-demo" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-demo-20.0.2.9-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-javadoc" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-javadoc-20.0.2.9-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-devel" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-devel-20.0.2.9-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-javadoc-zip" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-javadoc-zip-20.0.2.9-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-20.0.2.9-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-headless" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-headless-20.0.2.9-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-src" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-src-20.0.2.9-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-jmods" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-jmods-20.0.2.9-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-demo" release="1.rolling.oe2203sp1" version="20.0.2.9">
                         <filename>java-latest-openjdk-demo-20.0.2.9-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1607</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28879" id="CVE-2023-28879" title="CVE-2023-28879" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36664" id="CVE-2023-36664" title="CVE-2023-36664" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38559" id="CVE-2023-38559" title="CVE-2023-38559" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-28879)Artifex Ghostscript through 10.01.2 mishandles permission validation for pipe devices (with the %pipe% prefix or the | pipe character prefix).(CVE-2023-36664)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.(CVE-2023-38559)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-9.55.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-9.55.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="5.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1609</id>
          <title>An update for hyperscan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28711" id="CVE-2023-28711" title="CVE-2023-28711" type="cve"></reference>
          </references>
          <description>Insufficient control flow management in the Hyperscan Library maintained by Intel(R) before version 5.4.1 may allow an authenticated user to potentially enable denial of service via local access.(CVE-2023-28711)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hyperscan-debugsource" release="1.oe2203sp1" version="5.4.2">
                         <filename>hyperscan-debugsource-5.4.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hyperscan-devel" release="1.oe2203sp1" version="5.4.2">
                         <filename>hyperscan-devel-5.4.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hyperscan-debuginfo" release="1.oe2203sp1" version="5.4.2">
                         <filename>hyperscan-debuginfo-5.4.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hyperscan" release="1.oe2203sp1" version="5.4.2">
                         <filename>hyperscan-5.4.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hyperscan-devel" release="1.oe2203sp1" version="5.4.2">
                         <filename>hyperscan-devel-5.4.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hyperscan-debuginfo" release="1.oe2203sp1" version="5.4.2">
                         <filename>hyperscan-debuginfo-5.4.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hyperscan-debugsource" release="1.oe2203sp1" version="5.4.2">
                         <filename>hyperscan-debugsource-5.4.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hyperscan" release="1.oe2203sp1" version="5.4.2">
                         <filename>hyperscan-5.4.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1610</id>
          <title>An update for qt5-qtbase is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37369" id="CVE-2023-37369" title="CVE-2023-37369" type="cve"></reference>
          </references>
          <description>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-37369)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtbase-gui" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-postgresql" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-static" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debugsource" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-private-devel" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-devel" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-examples" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-odbc" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-mysql" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debuginfo" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qt5-qtbase-common" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-common-5.15.2-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-gui" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-private-devel" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-examples" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-postgresql" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-odbc" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debuginfo" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-static" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-mysql" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-devel" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debugsource" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase" release="9.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1615</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3865" id="CVE-2023-3865" title="CVE-2023-3865" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3866" id="CVE-2023-3866" title="CVE-2023-3866" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4132" id="CVE-2023-4132" title="CVE-2023-4132" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4273" id="CVE-2023-4273" title="CVE-2023-4273" type="cve"></reference>
          </references>
          <description>(CVE-2023-3865)(CVE-2023-3866)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-4132)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-4273)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.48.0.126.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.48.0.126.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.48.0.126.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1617</id>
          <title>An update for openjdk-11 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21835" id="CVE-2023-21835" title="CVE-2023-21835" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21937" id="CVE-2023-21937" title="CVE-2023-21937" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21967" id="CVE-2023-21967" title="CVE-2023-21967" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22006" id="CVE-2023-22006" title="CVE-2023-22006" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22036" id="CVE-2023-22036" title="CVE-2023-22036" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22041" id="CVE-2023-22041" title="CVE-2023-22041" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22049" id="CVE-2023-22049" title="CVE-2023-22049" type="cve"></reference>
          </references>
          <description>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-2022-40433)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-21835)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-21843)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-21937)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-21938)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-21939)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-21954)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-21967)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-21968)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-22006)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-22036)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). CVSS 3.1 Base Score 5.1 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N).(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, 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. CVSS 3.1 Base Score 3.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2023-22045)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. 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-22049)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-jmods-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-headless-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-devel-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-src-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-demo-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debuginfo" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-debuginfo-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-javadoc-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debugsource" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-debugsource-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-slowdebug-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-src-slowdebug-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc-zip" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-javadoc-zip-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.20.8-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debugsource" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-debugsource-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-demo-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-devel-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-headless-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-src-slowdebug-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-src-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-jmods-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-slowdebug" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-slowdebug-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debuginfo" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-debuginfo-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc-zip" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-javadoc-zip-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc" release="2.oe2203sp1" version="11.0.20.8">
                         <filename>java-11-openjdk-javadoc-11.0.20.8-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1622</id>
          <title>An update for php is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31631" id="CVE-2022-31631" title="CVE-2022-31631" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0567" id="CVE-2023-0567" title="CVE-2023-0567" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0568" id="CVE-2023-0568" title="CVE-2023-0568" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0662" id="CVE-2023-0662" title="CVE-2023-0662" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3247" id="CVE-2023-3247" title="CVE-2023-3247" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3823" id="CVE-2023-3823" title="CVE-2023-3823" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3824" id="CVE-2023-3824" title="CVE-2023-3824" type="cve"></reference>
          </references>
          <description>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-2022-31631)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-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, 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-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, 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-0662)In PHP versions 8.0.* before 8.0.29, 8.1.* before 8.1.20, 8.2.* before 8.2.7 when using SOAP HTTP Digest Authentication, random value generator was not checked for failure, and was using narrower range of values than it should have. In case of random generator failure, it could lead to a disclosure of 31 bits of uninitialized memory from the client to the server, and it also made easier to a malicious server to guess the client&#39;s nonce. (CVE-2023-3247)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-3823)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. (CVE-2023-3824)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="php-xml" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-enchant" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-help" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gd" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-soap" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-help" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="1.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1624</id>
          <title>An update for gdb is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39128" id="CVE-2023-39128" title="CVE-2023-39128" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-39128)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gdb-debugsource" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-debugsource-11.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-gdbserver" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-gdbserver-11.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-11.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-debuginfo" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-debuginfo-11.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-headless" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-headless-11.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gdb-help" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-help-11.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-11.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-gdbserver" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-gdbserver-11.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-headless" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-headless-11.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-debugsource" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-debugsource-11.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-debuginfo" release="6.oe2203sp1" version="11.1">
                         <filename>gdb-debuginfo-11.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1625</id>
          <title>An update for libtommath is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-36328" id="CVE-2023-36328" title="CVE-2023-36328" type="cve"></reference>
          </references>
          <description>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).(CVE-2023-36328)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtommath-devel" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-devel-1.2.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtommath-debugsource" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-debugsource-1.2.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtommath" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-1.2.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtommath-help" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-help-1.2.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtommath-debuginfo" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-debuginfo-1.2.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtommath-debuginfo" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-debuginfo-1.2.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtommath-debugsource" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-debugsource-1.2.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtommath-devel" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-devel-1.2.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtommath-help" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-help-1.2.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtommath" release="4.oe2203sp1" version="1.2.0">
                         <filename>libtommath-1.2.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1626</id>
          <title>An update for nasm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21528" id="CVE-2020-21528" title="CVE-2020-21528" type="cve"></reference>
          </references>
          <description>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.(CVE-2020-21528)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nasm-debugsource" release="6.oe2203sp1" version="2.15.05">
                         <filename>nasm-debugsource-2.15.05-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nasm" release="6.oe2203sp1" version="2.15.05">
                         <filename>nasm-2.15.05-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nasm-debuginfo" release="6.oe2203sp1" version="2.15.05">
                         <filename>nasm-debuginfo-2.15.05-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="nasm-help" release="6.oe2203sp1" version="2.15.05">
                         <filename>nasm-help-2.15.05-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm-debugsource" release="6.oe2203sp1" version="2.15.05">
                         <filename>nasm-debugsource-2.15.05-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm-debuginfo" release="6.oe2203sp1" version="2.15.05">
                         <filename>nasm-debuginfo-2.15.05-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nasm" release="6.oe2203sp1" version="2.15.05">
                         <filename>nasm-2.15.05-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1627</id>
          <title>An update for rubygem-railties is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38037" id="CVE-2023-38037" title="CVE-2023-38037" type="cve"></reference>
          </references>
          <description>(CVE-2023-38037)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rubygem-railties" release="2.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-railties-6.1.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-railties-doc" release="2.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-railties-doc-6.1.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1628</id>
          <title>An update for python-GitPython is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41040" id="CVE-2023-41040" title="CVE-2023-41040" type="cve"></reference>
          </references>
          <description> GitPython is a python library used to interact with Git repositories. In order to resolve some git references, GitPython reads files from the `.git` directory, in some places the name of the file being read is provided by the user, GitPython doesn&#39;t check if this file is located outside the `.git` directory. This allows an attacker to make GitPython read any file from the system. This vulnerability is present in https://github.com/gitpython-developers/GitPython/blob/1c8310d7cae144f74a671cbe17e51f63a830adbf/git/refs/symbolic.py#L174-L175. That code joins the base directory with a user given string without checking if the final path is located outside the base directory. This vulnerability cannot be used to read the contents of files but could in theory be used to trigger a denial of service for the program. This issue has not yet been addressed.(CVE-2023-41040)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-GitPython-help" release="2.oe2203sp1" version="3.1.32">
                         <filename>python-GitPython-help-3.1.32-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-GitPython" release="2.oe2203sp1" version="3.1.32">
                         <filename>python3-GitPython-3.1.32-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1630</id>
          <title>An update for open-vm-tools is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20867" id="CVE-2023-20867" title="CVE-2023-20867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20900" id="CVE-2023-20900" title="CVE-2023-20900" type="cve"></reference>
          </references>
          <description>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-20867)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-20900)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="open-vm-tools-debugsource" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-debugsource-12.0.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-sdmp" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-sdmp-12.0.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-desktop" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-desktop-12.0.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-test" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-test-12.0.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-debuginfo" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-debuginfo-12.0.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-devel" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-devel-12.0.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-12.0.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-debuginfo" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-debuginfo-12.0.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-test" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-test-12.0.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-debugsource" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-debugsource-12.0.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-salt-minion" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-salt-minion-12.0.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-devel" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-devel-12.0.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-sdmp" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-sdmp-12.0.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-12.0.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-desktop" release="3.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-desktop-12.0.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1632</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41080" id="CVE-2023-41080" title="CVE-2023-41080" type="cve"></reference>
          </references>
          <description>URL Redirection to Untrusted Site (&#39;Open Redirect&#39;) vulnerability in FORM authentication feature Apache Tomcat.This issue affects Apache Tomcat: from 11.0.0-M1 through 11.0.0-M10, from 10.1.0-M1 through 10.0.12, from 9.0.0-M1 through 9.0.79 and from 8.5.0 through 8.5.92.The vulnerability is limited to the ROOT (default) web application.(CVE-2023-41080)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="31.oe2203sp1" version="9.0.10">
                         <filename>tomcat-jsvc-9.0.10-31.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="31.oe2203sp1" version="9.0.10">
                         <filename>tomcat-help-9.0.10-31.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat" release="31.oe2203sp1" version="9.0.10">
                         <filename>tomcat-9.0.10-31.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1633</id>
          <title>An update for rubygem-activesupport is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38037" id="CVE-2023-38037" title="CVE-2023-38037" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-38037)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport-doc" release="6.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activesupport-doc-6.1.4.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport" release="6.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activesupport-6.1.4.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1635</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32247" id="CVE-2023-32247" title="CVE-2023-32247" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3777" id="CVE-2023-3777" title="CVE-2023-3777" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4015" id="CVE-2023-4015" title="CVE-2023-4015" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4206" id="CVE-2023-4206" title="CVE-2023-4206" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4207" id="CVE-2023-4207" title="CVE-2023-4207" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4208" id="CVE-2023-4208" title="CVE-2023-4208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4622" id="CVE-2023-4622" title="CVE-2023-4622" type="cve"></reference>
          </references>
          <description>A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the handling of SMB2_SESSION_SETUP commands. The issue results from the lack of control of resource consumption. An attacker can leverage this vulnerability to create a denial-of-service condition on the system.(CVE-2023-32247)A use-after-free vulnerability in the Linux kernel&#39;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&#39;s owner rule can also release the objects in certain circumstances.We recommend upgrading past commit 6eaf41e87a223ae6f8e7a28d6e78384ad7e407f8.(CVE-2023-3777)A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation.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.We recommend upgrading past commit 0a771f7b266b02d262900c75f1e175c7fe76fec2.(CVE-2023-4015)A use-after-free vulnerability in the Linux kernel&#39;s net/sched: cls_route component can be exploited to achieve local privilege escalation.When route4_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free.We recommend upgrading past commit b80b829e9e2c1b3f7aae34855e04d8f6ecaf13c8.(CVE-2023-4206)A use-after-free vulnerability in the Linux kernel&#39;s net/sched: cls_fw component can be exploited to achieve local privilege escalation.When fw_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free.We recommend upgrading past commit 76e42ae831991c828cffa8c37736ebfb831ad5ec.(CVE-2023-4207)A use-after-free vulnerability in the Linux kernel&#39;s net/sched: cls_u32 component can be exploited to achieve local privilege escalation.When u32_change() is called on an existing filter, the whole tcf_result struct is always copied into the new instance of the filter. This causes a problem when updating a filter bound to a class, as tcf_unbind_filter() is always called on the old instance in the success path, decreasing filter_cnt of the still referenced class and allowing it to be deleted, leading to a use-after-free.We recommend upgrading past commit 3044b16e7c6fe5d24b1cdbcf1bd0a9d92d1ebd81.(CVE-2023-4208)A use-after-free vulnerability in the Linux kernel&#39;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&#39;s recv queue without locking the queue. Thus there is a race where unix_stream_sendpage() could access an skb locklessly that is being released by garbage collection, resulting in use-after-free.We recommend upgrading past commit 790c2f9d15b594350ae9bca7b236f2b1859de02c.(CVE-2023-4622)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.49.0.127.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.49.0.127.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.49.0.127.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1641</id>
          <title>An update for djvulibre is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46310" id="CVE-2021-46310" title="CVE-2021-46310" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46312" id="CVE-2021-46312" title="CVE-2021-46312" type="cve"></reference>
          </references>
          <description>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-46310)An issue was discovered IW44EncodeCodec.cpp in djvulibre 3.5.28 in allows attackers to cause a denial of service via divide by zero.(CVE-2021-46312)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="djvulibre-devel" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-devel-3.5.27-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="djvulibre-help" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-help-3.5.27-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="djvulibre" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-3.5.27-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="djvulibre-debuginfo" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-debuginfo-3.5.27-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="djvulibre-debugsource" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-debugsource-3.5.27-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="djvulibre" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-3.5.27-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="djvulibre-debugsource" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-debugsource-3.5.27-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="djvulibre-debuginfo" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-debuginfo-3.5.27-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="djvulibre-devel" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-devel-3.5.27-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="djvulibre-help" release="19.oe2203sp1" version="3.5.27">
                         <filename>djvulibre-help-3.5.27-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1645</id>
          <title>An update for openjdk-1.8.0 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21549" id="CVE-2022-21549" title="CVE-2022-21549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40433" id="CVE-2022-40433" title="CVE-2022-40433" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21830" id="CVE-2023-21830" title="CVE-2023-21830" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21843" id="CVE-2023-21843" title="CVE-2023-21843" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21930" id="CVE-2023-21930" title="CVE-2023-21930" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21937" id="CVE-2023-21937" title="CVE-2023-21937" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21938" id="CVE-2023-21938" title="CVE-2023-21938" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21939" id="CVE-2023-21939" title="CVE-2023-21939" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21954" id="CVE-2023-21954" title="CVE-2023-21954" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21968" id="CVE-2023-21968" title="CVE-2023-21968" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22045" id="CVE-2023-22045" title="CVE-2023-22045" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22049" id="CVE-2023-22049" title="CVE-2023-22049" type="cve"></reference>
          </references>
          <description>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-21549)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-2022-40433)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-21830)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-21843)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-21930)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-21937)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-21938)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-21939)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-21954)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-21968)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. CVSS 3.1 Base Score 3.7 (Confidentiality impacts).  CVSS Vector: (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N).(CVE-2023-22045)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. 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-22049)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debuginfo" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debugsource" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-src-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.382.b05-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-javadoc-1.8.0.382.b05-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc-zip" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.382.b05-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-src-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debugsource" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debuginfo" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo-slowdebug" release="8.oe2203sp1" version="1.8.0.382.b05">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.382.b05-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1651</id>
          <title>An update for batik is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38398" id="CVE-2022-38398" title="CVE-2022-38398" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38648" id="CVE-2022-38648" title="CVE-2022-38648" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40146" id="CVE-2022-40146" title="CVE-2022-40146" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44729" id="CVE-2022-44729" title="CVE-2022-44729" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44730" id="CVE-2022-44730" title="CVE-2022-44730" type="cve"></reference>
          </references>
          <description>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-38398)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-38648)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-40146)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-44729)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.(CVE-2022-44730)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="batik" release="1.oe2203sp1" version="1.17">
                         <filename>batik-1.17-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="batik-help" release="1.oe2203sp1" version="1.17">
                         <filename>batik-help-1.17-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1652</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2906" id="CVE-2023-2906" title="CVE-2023-2906" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3649" id="CVE-2023-3649" title="CVE-2023-3649" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4511" id="CVE-2023-4511" title="CVE-2023-4511" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4513" id="CVE-2023-4513" title="CVE-2023-4513" type="cve"></reference>
          </references>
          <description>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-2906)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-3649)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-4511)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(CVE-2023-4513)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="3.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1653</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4733" id="CVE-2023-4733" title="CVE-2023-4733" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4734" id="CVE-2023-4734" title="CVE-2023-4734" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4735" id="CVE-2023-4735" title="CVE-2023-4735" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4736" id="CVE-2023-4736" title="CVE-2023-4736" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4738" id="CVE-2023-4738" title="CVE-2023-4738" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4750" id="CVE-2023-4750" title="CVE-2023-4750" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4752" id="CVE-2023-4752" title="CVE-2023-4752" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4781" id="CVE-2023-4781" title="CVE-2023-4781" type="cve"></reference>
          </references>
          <description>Use After Free in GitHub repository vim/vim prior to 9.0.1840.(CVE-2023-4733)Integer Overflow or Wraparound in GitHub repository vim/vim prior to 9.0.1846.(CVE-2023-4734)Out-of-bounds Write in GitHub repository vim/vim prior to 9.0.1847.(CVE-2023-4735)Untrusted Search Path in GitHub repository vim/vim prior to 9.0.1833.(CVE-2023-4736)Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1848.(CVE-2023-4738)Use After Free in GitHub repository vim/vim prior to 9.0.1857.(CVE-2023-4750)Use After Free in GitHub repository vim/vim prior to 9.0.1858.(CVE-2023-4752)Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1873.(CVE-2023-4781)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="17.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="17.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="17.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="17.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="17.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="17.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="17.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="17.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="17.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="17.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="17.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="17.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="17.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1656</id>
          <title>An update for freerdp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39350" id="CVE-2023-39350" title="CVE-2023-39350" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39351" id="CVE-2023-39351" title="CVE-2023-39351" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39352" id="CVE-2023-39352" title="CVE-2023-39352" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39353" id="CVE-2023-39353" title="CVE-2023-39353" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39354" id="CVE-2023-39354" title="CVE-2023-39354" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39356" id="CVE-2023-39356" title="CVE-2023-39356" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40181" id="CVE-2023-40181" title="CVE-2023-40181" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40186" id="CVE-2023-40186" title="CVE-2023-40186" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40188" id="CVE-2023-40188" title="CVE-2023-40188" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40567" id="CVE-2023-40567" title="CVE-2023-40567" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40569" id="CVE-2023-40569" title="CVE-2023-40569" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40589" id="CVE-2023-40589" title="CVE-2023-40589" type="cve"></reference>
          </references>
          <description>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-39350)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-39351)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-39352)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-39353)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-39354)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-39356)FreeRDP is a free implementation of the Remote Desktop Protocol (RDP), released under the Apache license. Affected versions are subject to an Integer-Underflow leading to Out-Of-Bound Read in the `zgfx_decompress_segment` function. In the context of `CopyMemory`, it&#39;s possible to read data beyond the transmitted packet range and likely cause a crash. This issue has been addressed in versions 2.11.0 and 3.0.0-beta3. Users are advised to upgrade. There are no known workarounds for this issue.(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 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-40186)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-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 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-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 `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-40569)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.(CVE-2023-40589)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="freerdp" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-2.11.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libwinpr-devel" release="1.oe2203sp1" version="2.11.1">
                         <filename>libwinpr-devel-2.11.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-help" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-help-2.11.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-devel" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-devel-2.11.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-debuginfo" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-debuginfo-2.11.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libwinpr" release="1.oe2203sp1" version="2.11.1">
                         <filename>libwinpr-2.11.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-debugsource" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-debugsource-2.11.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libwinpr-devel" release="1.oe2203sp1" version="2.11.1">
                         <filename>libwinpr-devel-2.11.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libwinpr" release="1.oe2203sp1" version="2.11.1">
                         <filename>libwinpr-2.11.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-devel" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-devel-2.11.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-help" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-help-2.11.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-2.11.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-debugsource" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-debugsource-2.11.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-debuginfo" release="1.oe2203sp1" version="2.11.1">
                         <filename>freerdp-debuginfo-2.11.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1657</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3354" id="CVE-2023-3354" title="CVE-2023-3354" type="cve"></reference>
          </references>
          <description>A flaw was found in the QEMU built-in VNC server. When a client connects to the VNC server, QEMU checks whether the current number of connections crosses a certain threshold and if so, cleans up the previous connection. If the previous connection happens to be in the handshake phase and fails, QEMU cleans up the connection again, resulting in a NULL pointer dereference issue. This could allow a remote unauthenticated client to cause a denial of service.(CVE-2023-3354)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-80.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-80.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="80.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-80.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1658</id>
          <title>An update for mosquitto is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28366" id="CVE-2023-28366" title="CVE-2023-28366" type="cve"></reference>
          </references>
          <description>The broker in Eclipse Mosquitto 1.3.2 through 2.x before 2.0.16 has a memory leak that can be abused remotely when a client sends many QoS 2 messages with duplicate message IDs, and fails to respond to PUBREC commands. This occurs because of mishandling of EAGAIN from the libc send function.(CVE-2023-28366)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mosquitto-devel" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-devel-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debugsource" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debugsource-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debuginfo" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debuginfo-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-devel" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-devel-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debuginfo" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debuginfo-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debugsource" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debugsource-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1660</id>
          <title>An update for mutt is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4874" id="CVE-2023-4874" title="CVE-2023-4874" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4875" id="CVE-2023-4875" title="CVE-2023-4875" type="cve"></reference>
          </references>
          <description>Null pointer dereference when viewing a specially crafted email in Mutt &gt;1.5.2 &lt;2.2.12(CVE-2023-4874)Null pointer dereference when composing from a specially crafted draft message in Mutt &gt;1.5.2 &lt;2.2.12(CVE-2023-4875)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="5" arch="aarch64" name="mutt-debuginfo" release="1.oe2203sp1" version="2.2.12">
                         <filename>mutt-debuginfo-2.2.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="mutt" release="1.oe2203sp1" version="2.2.12">
                         <filename>mutt-2.2.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="mutt-debugsource" release="1.oe2203sp1" version="2.2.12">
                         <filename>mutt-debugsource-2.2.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="noarch" name="mutt-help" release="1.oe2203sp1" version="2.2.12">
                         <filename>mutt-help-2.2.12-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="mutt-debuginfo" release="1.oe2203sp1" version="2.2.12">
                         <filename>mutt-debuginfo-2.2.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="mutt-debugsource" release="1.oe2203sp1" version="2.2.12">
                         <filename>mutt-debugsource-2.2.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="mutt" release="1.oe2203sp1" version="2.2.12">
                         <filename>mutt-2.2.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1661</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41164" id="CVE-2023-41164" title="CVE-2023-41164" type="cve"></reference>
          </references>
          <description>An uncontrolled resource consumption vulnerability was found in Django. Feeding certain inputs with a very large number of Unicode characters to the URI to IRI encoder function can lead to a denial of service.(CVE-2023-41164)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="6.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="6.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1664</id>
          <title>An update for skopeo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24537" id="CVE-2023-24537" title="CVE-2023-24537" type="cve"></reference>
          </references>
          <description>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-24537)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="skopeo-debugsource" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debugsource-1.5.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="skopeo-debuginfo" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debuginfo-1.5.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="skopeo" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-1.5.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="containers-common" release="3.oe2203sp1" version="1.5.2">
                         <filename>containers-common-1.5.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo-debugsource" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debugsource-1.5.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-1.5.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo-debuginfo" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debuginfo-1.5.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="containers-common" release="3.oe2203sp1" version="1.5.2">
                         <filename>containers-common-1.5.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1669</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45887" id="CVE-2022-45887" title="CVE-2022-45887" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-20588" id="CVE-2023-20588" title="CVE-2023-20588" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21400" id="CVE-2023-21400" title="CVE-2023-21400" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32249" id="CVE-2023-32249" title="CVE-2023-32249" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32251" id="CVE-2023-32251" title="CVE-2023-32251" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32253" id="CVE-2023-32253" title="CVE-2023-32253" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4881" id="CVE-2023-4881" title="CVE-2023-4881" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4921" id="CVE-2023-4921" title="CVE-2023-4921" type="cve"></reference>
          </references>
          <description>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-45887)A division-by-zero error on some AMD processors can potentially return speculative data resulting in loss of confidentiality. (CVE-2023-20588)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-21400)VUL-0: CVE-2023-32249: kernel: Linux Kernel ksmbd Multichannel Improper Authentication Session Hijack Vulnerability(CVE-2023-32249)VUL-0: CVE-2023-32251: kernel: Linux Kernel ksmbd Improper Restriction of Excessive Authentication Attempts Protection Bypass Vulnerability(CVE-2023-32251)VUL-0: CVE-2023-32253: kernel: Linux Kernel ksmbd Session Deadlock Denial-of-Service Vulnerability(CVE-2023-32253)** REJECT ** 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-4881)A use-after-free vulnerability in the Linux kernel&#39;s net/sched: sch_qfq component can be exploited to achieve local privilege escalation.When the plug qdisc is used as a class of the qfq qdisc, sending network packets triggers use-after-free in qfq_dequeue() due to the incorrect .peek handler of sch_plug and lack of error checking in agg_dequeue().We recommend upgrading past commit 8fc134fee27f2263988ae38920bc03da416b03d8.(CVE-2023-4921)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="bpftool" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="kernel-source" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.50.0.129.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.50.0.129.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.50.0.129.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1674</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15670" id="CVE-2020-15670" title="CVE-2020-15670" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15673" id="CVE-2020-15673" title="CVE-2020-15673" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15674" id="CVE-2020-15674" title="CVE-2020-15674" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15675" id="CVE-2020-15675" title="CVE-2020-15675" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15680" id="CVE-2020-15680" title="CVE-2020-15680" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15681" id="CVE-2020-15681" title="CVE-2020-15681" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15682" id="CVE-2020-15682" title="CVE-2020-15682" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15683" id="CVE-2020-15683" title="CVE-2020-15683" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-15684" id="CVE-2020-15684" title="CVE-2020-15684" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-16012" id="CVE-2020-16012" title="CVE-2020-16012" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-16044" id="CVE-2020-16044" title="CVE-2020-16044" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26950" id="CVE-2020-26950" title="CVE-2020-26950" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26951" id="CVE-2020-26951" title="CVE-2020-26951" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26953" id="CVE-2020-26953" title="CVE-2020-26953" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26956" id="CVE-2020-26956" title="CVE-2020-26956" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26958" id="CVE-2020-26958" title="CVE-2020-26958" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26959" id="CVE-2020-26959" title="CVE-2020-26959" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26960" id="CVE-2020-26960" title="CVE-2020-26960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26961" id="CVE-2020-26961" title="CVE-2020-26961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26962" id="CVE-2020-26962" title="CVE-2020-26962" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26965" id="CVE-2020-26965" title="CVE-2020-26965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26968" id="CVE-2020-26968" title="CVE-2020-26968" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26969" id="CVE-2020-26969" title="CVE-2020-26969" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26971" id="CVE-2020-26971" title="CVE-2020-26971" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26972" id="CVE-2020-26972" title="CVE-2020-26972" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26973" id="CVE-2020-26973" title="CVE-2020-26973" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26974" id="CVE-2020-26974" title="CVE-2020-26974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26976" id="CVE-2020-26976" title="CVE-2020-26976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26978" id="CVE-2020-26978" title="CVE-2020-26978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-26979" id="CVE-2020-26979" title="CVE-2020-26979" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35111" id="CVE-2020-35111" title="CVE-2020-35111" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35113" id="CVE-2020-35113" title="CVE-2020-35113" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35114" id="CVE-2020-35114" title="CVE-2020-35114" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23953" id="CVE-2021-23953" title="CVE-2021-23953" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23954" id="CVE-2021-23954" title="CVE-2021-23954" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23955" id="CVE-2021-23955" title="CVE-2021-23955" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23956" id="CVE-2021-23956" title="CVE-2021-23956" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23958" id="CVE-2021-23958" title="CVE-2021-23958" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23960" id="CVE-2021-23960" title="CVE-2021-23960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23961" id="CVE-2021-23961" title="CVE-2021-23961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23962" id="CVE-2021-23962" title="CVE-2021-23962" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23963" id="CVE-2021-23963" title="CVE-2021-23963" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23964" id="CVE-2021-23964" title="CVE-2021-23964" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23965" id="CVE-2021-23965" title="CVE-2021-23965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23968" id="CVE-2021-23968" title="CVE-2021-23968" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23969" id="CVE-2021-23969" title="CVE-2021-23969" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23970" id="CVE-2021-23970" title="CVE-2021-23970" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23971" id="CVE-2021-23971" title="CVE-2021-23971" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23972" id="CVE-2021-23972" title="CVE-2021-23972" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23973" id="CVE-2021-23973" title="CVE-2021-23973" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23974" id="CVE-2021-23974" title="CVE-2021-23974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23975" id="CVE-2021-23975" title="CVE-2021-23975" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23978" id="CVE-2021-23978" title="CVE-2021-23978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23979" id="CVE-2021-23979" title="CVE-2021-23979" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23981" id="CVE-2021-23981" title="CVE-2021-23981" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23982" id="CVE-2021-23982" title="CVE-2021-23982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23983" id="CVE-2021-23983" title="CVE-2021-23983" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23984" id="CVE-2021-23984" title="CVE-2021-23984" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23985" id="CVE-2021-23985" title="CVE-2021-23985" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23986" id="CVE-2021-23986" title="CVE-2021-23986" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23987" id="CVE-2021-23987" title="CVE-2021-23987" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23988" id="CVE-2021-23988" title="CVE-2021-23988" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23994" id="CVE-2021-23994" title="CVE-2021-23994" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23995" id="CVE-2021-23995" title="CVE-2021-23995" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23996" id="CVE-2021-23996" title="CVE-2021-23996" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23997" id="CVE-2021-23997" title="CVE-2021-23997" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23998" id="CVE-2021-23998" title="CVE-2021-23998" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23999" id="CVE-2021-23999" title="CVE-2021-23999" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24000" id="CVE-2021-24000" title="CVE-2021-24000" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24001" id="CVE-2021-24001" title="CVE-2021-24001" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-24002" id="CVE-2021-24002" title="CVE-2021-24002" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29944" id="CVE-2021-29944" title="CVE-2021-29944" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29945" id="CVE-2021-29945" title="CVE-2021-29945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29946" id="CVE-2021-29946" title="CVE-2021-29946" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29947" id="CVE-2021-29947" title="CVE-2021-29947" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29952" id="CVE-2021-29952" title="CVE-2021-29952" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29953" id="CVE-2021-29953" title="CVE-2021-29953" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29955" id="CVE-2021-29955" title="CVE-2021-29955" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29959" id="CVE-2021-29959" title="CVE-2021-29959" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29960" id="CVE-2021-29960" title="CVE-2021-29960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29961" id="CVE-2021-29961" title="CVE-2021-29961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29965" id="CVE-2021-29965" title="CVE-2021-29965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29966" id="CVE-2021-29966" title="CVE-2021-29966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29967" id="CVE-2021-29967" title="CVE-2021-29967" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29970" id="CVE-2021-29970" title="CVE-2021-29970" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29972" id="CVE-2021-29972" title="CVE-2021-29972" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29974" id="CVE-2021-29974" title="CVE-2021-29974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29975" id="CVE-2021-29975" title="CVE-2021-29975" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29976" id="CVE-2021-29976" title="CVE-2021-29976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29977" id="CVE-2021-29977" title="CVE-2021-29977" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29980" id="CVE-2021-29980" title="CVE-2021-29980" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29981" id="CVE-2021-29981" title="CVE-2021-29981" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29982" id="CVE-2021-29982" title="CVE-2021-29982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29984" id="CVE-2021-29984" title="CVE-2021-29984" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29985" id="CVE-2021-29985" title="CVE-2021-29985" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29986" id="CVE-2021-29986" title="CVE-2021-29986" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29987" id="CVE-2021-29987" title="CVE-2021-29987" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29988" id="CVE-2021-29988" title="CVE-2021-29988" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29989" id="CVE-2021-29989" title="CVE-2021-29989" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29990" id="CVE-2021-29990" title="CVE-2021-29990" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-29991" id="CVE-2021-29991" title="CVE-2021-29991" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-30547" id="CVE-2021-30547" title="CVE-2021-30547" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32810" id="CVE-2021-32810" title="CVE-2021-32810" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38491" id="CVE-2021-38491" title="CVE-2021-38491" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38493" id="CVE-2021-38493" title="CVE-2021-38493" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38494" id="CVE-2021-38494" title="CVE-2021-38494" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38496" id="CVE-2021-38496" title="CVE-2021-38496" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38497" id="CVE-2021-38497" title="CVE-2021-38497" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38498" id="CVE-2021-38498" title="CVE-2021-38498" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38499" id="CVE-2021-38499" title="CVE-2021-38499" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38500" id="CVE-2021-38500" title="CVE-2021-38500" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38501" id="CVE-2021-38501" title="CVE-2021-38501" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38503" id="CVE-2021-38503" title="CVE-2021-38503" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38504" id="CVE-2021-38504" title="CVE-2021-38504" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38506" id="CVE-2021-38506" title="CVE-2021-38506" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38507" id="CVE-2021-38507" title="CVE-2021-38507" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38508" id="CVE-2021-38508" title="CVE-2021-38508" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38509" id="CVE-2021-38509" title="CVE-2021-38509" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38510" id="CVE-2021-38510" title="CVE-2021-38510" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-4140" id="CVE-2021-4140" title="CVE-2021-4140" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43531" id="CVE-2021-43531" title="CVE-2021-43531" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43532" id="CVE-2021-43532" title="CVE-2021-43532" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43533" id="CVE-2021-43533" title="CVE-2021-43533" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43534" id="CVE-2021-43534" title="CVE-2021-43534" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43535" id="CVE-2021-43535" title="CVE-2021-43535" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43536" id="CVE-2021-43536" title="CVE-2021-43536" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43537" id="CVE-2021-43537" title="CVE-2021-43537" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43538" id="CVE-2021-43538" title="CVE-2021-43538" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43539" id="CVE-2021-43539" title="CVE-2021-43539" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43540" id="CVE-2021-43540" title="CVE-2021-43540" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43541" id="CVE-2021-43541" title="CVE-2021-43541" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43542" id="CVE-2021-43542" title="CVE-2021-43542" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43543" id="CVE-2021-43543" title="CVE-2021-43543" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43545" id="CVE-2021-43545" title="CVE-2021-43545" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43546" id="CVE-2021-43546" title="CVE-2021-43546" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0511" id="CVE-2022-0511" title="CVE-2022-0511" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0843" id="CVE-2022-0843" title="CVE-2022-0843" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1097" id="CVE-2022-1097" title="CVE-2022-1097" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1196" id="CVE-2022-1196" title="CVE-2022-1196" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1529" id="CVE-2022-1529" title="CVE-2022-1529" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1802" id="CVE-2022-1802" title="CVE-2022-1802" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1919" id="CVE-2022-1919" title="CVE-2022-1919" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2200" id="CVE-2022-2200" title="CVE-2022-2200" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22737" id="CVE-2022-22737" title="CVE-2022-22737" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22738" id="CVE-2022-22738" title="CVE-2022-22738" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22739" id="CVE-2022-22739" title="CVE-2022-22739" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22740" id="CVE-2022-22740" title="CVE-2022-22740" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22741" id="CVE-2022-22741" title="CVE-2022-22741" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22742" id="CVE-2022-22742" title="CVE-2022-22742" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22743" id="CVE-2022-22743" title="CVE-2022-22743" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22745" id="CVE-2022-22745" title="CVE-2022-22745" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22747" id="CVE-2022-22747" title="CVE-2022-22747" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22748" id="CVE-2022-22748" title="CVE-2022-22748" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22754" id="CVE-2022-22754" title="CVE-2022-22754" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22755" id="CVE-2022-22755" title="CVE-2022-22755" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22756" id="CVE-2022-22756" title="CVE-2022-22756" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22757" id="CVE-2022-22757" title="CVE-2022-22757" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22759" id="CVE-2022-22759" title="CVE-2022-22759" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22760" id="CVE-2022-22760" title="CVE-2022-22760" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22761" id="CVE-2022-22761" title="CVE-2022-22761" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-22763" id="CVE-2022-22763" title="CVE-2022-22763" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24713" id="CVE-2022-24713" title="CVE-2022-24713" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26381" id="CVE-2022-26381" title="CVE-2022-26381" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26382" id="CVE-2022-26382" title="CVE-2022-26382" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26383" id="CVE-2022-26383" title="CVE-2022-26383" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26384" id="CVE-2022-26384" title="CVE-2022-26384" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26385" id="CVE-2022-26385" title="CVE-2022-26385" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26386" id="CVE-2022-26386" title="CVE-2022-26386" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26387" id="CVE-2022-26387" title="CVE-2022-26387" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26485" id="CVE-2022-26485" title="CVE-2022-26485" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26486" id="CVE-2022-26486" title="CVE-2022-26486" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28281" id="CVE-2022-28281" title="CVE-2022-28281" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28282" id="CVE-2022-28282" title="CVE-2022-28282" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28283" id="CVE-2022-28283" title="CVE-2022-28283" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28284" id="CVE-2022-28284" title="CVE-2022-28284" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28285" id="CVE-2022-28285" title="CVE-2022-28285" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28286" id="CVE-2022-28286" title="CVE-2022-28286" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28287" id="CVE-2022-28287" title="CVE-2022-28287" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-28289" id="CVE-2022-28289" title="CVE-2022-28289" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29909" id="CVE-2022-29909" title="CVE-2022-29909" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29911" id="CVE-2022-29911" title="CVE-2022-29911" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29912" id="CVE-2022-29912" title="CVE-2022-29912" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29914" id="CVE-2022-29914" title="CVE-2022-29914" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29915" id="CVE-2022-29915" title="CVE-2022-29915" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29916" id="CVE-2022-29916" title="CVE-2022-29916" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-29918" id="CVE-2022-29918" title="CVE-2022-29918" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31736" id="CVE-2022-31736" title="CVE-2022-31736" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31737" id="CVE-2022-31737" title="CVE-2022-31737" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31738" id="CVE-2022-31738" title="CVE-2022-31738" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31740" id="CVE-2022-31740" title="CVE-2022-31740" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31741" id="CVE-2022-31741" title="CVE-2022-31741" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31742" id="CVE-2022-31742" title="CVE-2022-31742" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31743" id="CVE-2022-31743" title="CVE-2022-31743" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31744" id="CVE-2022-31744" title="CVE-2022-31744" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31745" id="CVE-2022-31745" title="CVE-2022-31745" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-31748" id="CVE-2022-31748" title="CVE-2022-31748" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3266" id="CVE-2022-3266" title="CVE-2022-3266" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34468" id="CVE-2022-34468" title="CVE-2022-34468" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34469" id="CVE-2022-34469" title="CVE-2022-34469" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34470" id="CVE-2022-34470" title="CVE-2022-34470" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34471" id="CVE-2022-34471" title="CVE-2022-34471" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34472" id="CVE-2022-34472" title="CVE-2022-34472" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34473" id="CVE-2022-34473" title="CVE-2022-34473" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34474" id="CVE-2022-34474" title="CVE-2022-34474" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34475" id="CVE-2022-34475" title="CVE-2022-34475" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34476" id="CVE-2022-34476" title="CVE-2022-34476" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34477" id="CVE-2022-34477" title="CVE-2022-34477" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34479" id="CVE-2022-34479" title="CVE-2022-34479" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34480" id="CVE-2022-34480" title="CVE-2022-34480" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34481" id="CVE-2022-34481" title="CVE-2022-34481" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34482" id="CVE-2022-34482" title="CVE-2022-34482" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34483" id="CVE-2022-34483" title="CVE-2022-34483" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34484" id="CVE-2022-34484" title="CVE-2022-34484" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34485" id="CVE-2022-34485" title="CVE-2022-34485" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36318" id="CVE-2022-36318" title="CVE-2022-36318" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36319" id="CVE-2022-36319" title="CVE-2022-36319" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38472" id="CVE-2022-38472" title="CVE-2022-38472" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38473" id="CVE-2022-38473" title="CVE-2022-38473" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38477" id="CVE-2022-38477" title="CVE-2022-38477" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-38478" id="CVE-2022-38478" title="CVE-2022-38478" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40956" id="CVE-2022-40956" title="CVE-2022-40956" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40957" id="CVE-2022-40957" title="CVE-2022-40957" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40958" id="CVE-2022-40958" title="CVE-2022-40958" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40959" id="CVE-2022-40959" title="CVE-2022-40959" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40960" id="CVE-2022-40960" title="CVE-2022-40960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40962" id="CVE-2022-40962" title="CVE-2022-40962" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42928" id="CVE-2022-42928" title="CVE-2022-42928" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45408" id="CVE-2022-45408" title="CVE-2022-45408" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45409" id="CVE-2022-45409" title="CVE-2022-45409" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45410" id="CVE-2022-45410" title="CVE-2022-45410" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45411" id="CVE-2022-45411" title="CVE-2022-45411" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45412" id="CVE-2022-45412" title="CVE-2022-45412" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45416" id="CVE-2022-45416" title="CVE-2022-45416" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45418" id="CVE-2022-45418" title="CVE-2022-45418" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45420" id="CVE-2022-45420" title="CVE-2022-45420" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45421" id="CVE-2022-45421" title="CVE-2022-45421" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46871" id="CVE-2022-46871" title="CVE-2022-46871" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46874" id="CVE-2022-46874" title="CVE-2022-46874" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46875" id="CVE-2022-46875" title="CVE-2022-46875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46878" id="CVE-2022-46878" title="CVE-2022-46878" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-46882" id="CVE-2022-46882" title="CVE-2022-46882" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0767" id="CVE-2023-0767" title="CVE-2023-0767" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1945" id="CVE-2023-1945" title="CVE-2023-1945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23598" id="CVE-2023-23598" title="CVE-2023-23598" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23599" id="CVE-2023-23599" title="CVE-2023-23599" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23601" id="CVE-2023-23601" title="CVE-2023-23601" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23602" id="CVE-2023-23602" title="CVE-2023-23602" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23603" id="CVE-2023-23603" title="CVE-2023-23603" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25728" id="CVE-2023-25728" title="CVE-2023-25728" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25729" id="CVE-2023-25729" title="CVE-2023-25729" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25730" id="CVE-2023-25730" title="CVE-2023-25730" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25732" id="CVE-2023-25732" title="CVE-2023-25732" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25735" id="CVE-2023-25735" title="CVE-2023-25735" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25737" id="CVE-2023-25737" title="CVE-2023-25737" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25739" id="CVE-2023-25739" title="CVE-2023-25739" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25742" id="CVE-2023-25742" title="CVE-2023-25742" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25751" id="CVE-2023-25751" title="CVE-2023-25751" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-25752" id="CVE-2023-25752" title="CVE-2023-25752" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28162" id="CVE-2023-28162" title="CVE-2023-28162" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28164" id="CVE-2023-28164" title="CVE-2023-28164" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28176" id="CVE-2023-28176" title="CVE-2023-28176" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29533" id="CVE-2023-29533" title="CVE-2023-29533" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29535" id="CVE-2023-29535" title="CVE-2023-29535" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29536" id="CVE-2023-29536" title="CVE-2023-29536" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29539" id="CVE-2023-29539" title="CVE-2023-29539" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29541" id="CVE-2023-29541" title="CVE-2023-29541" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29548" id="CVE-2023-29548" title="CVE-2023-29548" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29550" id="CVE-2023-29550" title="CVE-2023-29550" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32205" id="CVE-2023-32205" title="CVE-2023-32205" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32206" id="CVE-2023-32206" title="CVE-2023-32206" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32207" id="CVE-2023-32207" title="CVE-2023-32207" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32211" id="CVE-2023-32211" title="CVE-2023-32211" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32212" id="CVE-2023-32212" title="CVE-2023-32212" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32213" id="CVE-2023-32213" title="CVE-2023-32213" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32215" id="CVE-2023-32215" title="CVE-2023-32215" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37201" id="CVE-2023-37201" title="CVE-2023-37201" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37202" id="CVE-2023-37202" title="CVE-2023-37202" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37207" id="CVE-2023-37207" title="CVE-2023-37207" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37208" id="CVE-2023-37208" title="CVE-2023-37208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37211" id="CVE-2023-37211" title="CVE-2023-37211" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4045" id="CVE-2023-4045" title="CVE-2023-4045" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4046" id="CVE-2023-4046" title="CVE-2023-4046" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4047" id="CVE-2023-4047" title="CVE-2023-4047" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4048" id="CVE-2023-4048" title="CVE-2023-4048" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4049" id="CVE-2023-4049" title="CVE-2023-4049" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4050" id="CVE-2023-4050" title="CVE-2023-4050" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4054" id="CVE-2023-4054" title="CVE-2023-4054" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4055" id="CVE-2023-4055" title="CVE-2023-4055" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4056" id="CVE-2023-4056" title="CVE-2023-4056" type="cve"></reference>
          </references>
          <description>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-15670)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-15673)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-15674)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-15675)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-15680)When multiple WASM threads had a reference to a module, and were looking up exported functions, one WASM thread could have overwritten another&#39;s entry in a shared stub table, resulting in a potentially exploitable crash. This vulnerability affects Firefox &lt; 82.(CVE-2020-15681)When a link to an external protocol was clicked, a prompt was presented that allowed the user to choose what application to open it in. An attacker could induce that prompt to be associated with an origin they didn&#39;t control, resulting in a spoofing attack. This was fixed by changing external protocol prompts to be tab-modal while also ensuring they could not be incorrectly associated with a different origin. This vulnerability affects Firefox &lt; 82.(CVE-2020-15682)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-15683)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-15684)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-16012)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-16044)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-26950)(CVE-2020-26951)(CVE-2020-26953)(CVE-2020-26956)(CVE-2020-26958)(CVE-2020-26959)(CVE-2020-26960)(CVE-2020-26961)(CVE-2020-26962)(CVE-2020-26965)(CVE-2020-26968)(CVE-2020-26969)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-26971)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-26972)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-26973)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-26974)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-26976)Using techniques that built on the slipstream research, a malicious webpage could have exposed both an internal network&#39;s hosts as well as services running on the user&#39;s local machine. This vulnerability affects Firefox &lt; 84, Thunderbird &lt; 78.6, and Firefox ESR &lt; 78.6.(CVE-2020-26978)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-26979)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-35111)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-35113)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-2020-35114)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-23953)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-23954)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-23955)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-23956)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-23958)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-23960)Further techniques that built on the slipstream research combined with a malicious webpage could have exposed both an internal network&#39;s hosts as well as services running on the user&#39;s local machine. This vulnerability affects Firefox &lt; 85.(CVE-2021-23961)Incorrect use of the &#39;&lt;RowCountChanged&gt;&#39; method could have led to a user-after-poison and a potentially exploitable crash. This vulnerability affects Firefox &lt; 85.(CVE-2021-23962)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-23963)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-23964)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-23965)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-23968)As specified in the W3C Content Security Policy draft, when creating a violation report, &#34;User agents need to ensure that the source file is the URL requested by the page, pre-redirects. If that’s not possible, user agents need to strip the URL down to an origin to avoid unintentional leakage.&#34; Under certain types of redirects, Firefox incorrectly set the source file to be the destination of the redirects. This was fixed to be the redirect destination&#39;s origin. This vulnerability affects Firefox &lt; 86, Thunderbird &lt; 78.8, and Firefox ESR &lt; 78.8.(CVE-2021-23969)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-23970)When processing a redirect with a conflicting Referrer-Policy, Firefox would have adopted the redirect&#39;s Referrer-Policy. This would have potentially resulted in more information than intended by the original origin being provided to the destination of the redirect. This vulnerability affects Firefox &lt; 86.(CVE-2021-23971)One phishing tactic on the web is to provide a link with HTTP Auth. For example &#39;https://www.phishingtarget.com@evil.com&#39;. To mitigate this type of attack, Firefox will display a warning dialog; however, this warning dialog would not have been displayed if evil.com used a redirect that was cached by the browser. This vulnerability affects Firefox &lt; 86.(CVE-2021-23972)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-23973)The DOMParser API did not properly process &#39;&lt;noscript&gt;&#39; elements for escaping. This could be used as an mXSS vector to bypass an HTML Sanitizer. This vulnerability affects Firefox &lt; 86.(CVE-2021-23974)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-23975)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-23978)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-23979)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-23981)Using techniques that built on the slipstream research, a malicious webpage could have scanned both an internal network&#39;s hosts as well as services running on the user&#39;s local machine utilizing WebRTC connections. This vulnerability affects Firefox ESR &lt; 78.9, Firefox &lt; 87, and Thunderbird &lt; 78.9.(CVE-2021-23982)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-23983)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-23984)If an attacker is able to alter specific about:config values (for example malware running on the user&#39;s computer), the Devtools remote debugging feature could have been enabled in a way that was unnoticable to the user. This would have allowed a remote attacker (able to make a direct network connection to the victim) to monitor the user&#39;s browsing activity and (plaintext) network traffic. This was addressed by providing a visual cue when Devtools has an open network socket. This vulnerability affects Firefox &lt; 87.(CVE-2021-23985)A malicious extension with the &#39;search&#39; permission could have installed a new search engine whose favicon referenced a cross-origin URL. The response to this cross-origin request could have been read by the extension, allowing a same-origin policy bypass by the extension, which should not have cross-origin permissions. This cross-origin request was made without cookies, so the sensitive information disclosed by the violation was limited to local-network resources or resources that perform IP-based authentication. This vulnerability affects Firefox &lt; 87.(CVE-2021-23986)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-23987)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-23988)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-23994)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-23995)By utilizing 3D CSS in conjunction with Javascript, content could have been rendered outside the webpage&#39;s viewport, resulting in a spoofing attack that could have been used for phishing or other attacks on a user. This vulnerability affects Firefox &lt; 88.(CVE-2021-23996)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-23997)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-23998)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-23999)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 &lt;input type=&#34;file&#34;&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-24000)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-24001)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-24002)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-29944)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-29945)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-29946)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-29947)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-29952)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-29953)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-29955)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-29959)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-29960)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-29961)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-29965)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-29966)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-29967)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-29970)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-29972)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-29974)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-29975)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-29976)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-29977)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-29980)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-29981)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-29982)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-29984)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-29985)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-29986)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-29987)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-29988)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-29989)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-29990)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-29991)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-30547)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-32810)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-38491)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-38493)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-38494)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-38496)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-38497)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-38498)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-38499)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-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 Firefox &lt; 93, Thunderbird &lt; 91.2, and Firefox ESR &lt; 91.2.(CVE-2021-38501)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-38503)When interacting with an HTML input element&#39;s file picker dialog with webkitdirectory set, a use-after-free could have resulted, leading to memory corruption and a potentially exploitable crash. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.(CVE-2021-38504)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-38506)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-38507)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-38508)Due to an unusual sequence of attacker-controlled events, a Javascript alert() dialog with arbitrary (although unstyled) contents could be displayed over top an uncontrolled webpage of the attacker&#39;s choosing. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.(CVE-2021-38509)The executable file warning was not presented when downloading .inetloc files, which, due to a flaw in Mac OS, can run commands on a user&#39;s computer.*Note: This issue only affected Mac OS operating systems. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 94, Thunderbird &lt; 91.3, and Firefox ESR &lt; 91.3.(CVE-2021-38510)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-4140)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-43531)The &#39;Copy Image Link&#39; context menu action would copy the final image URL after redirects. By embedding an image that triggered authentication flows - in conjunction with a Content Security Policy that stopped a redirection chain in the middle - the final image URL could be one that contained an authentication token used to takeover a user account. If a website tricked a user into copy and pasting the image link back to the page, the page would be able to steal the authentication tokens. This was fixed by making the action return the original URL, before any redirects. This vulnerability affects Firefox &lt; 94.(CVE-2021-43532)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-43533)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-43534)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-43535)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-43536)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-43537)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-43538)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-43539)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-43540)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-43541)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-43542)Documents loaded with the CSP sandbox directive could have escaped the sandbox&#39;s script restriction by embedding additional content. This vulnerability affects Thunderbird &lt; 91.4.0, Firefox ESR &lt; 91.4.0, and Firefox &lt; 95.(CVE-2021-43543)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-43545)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-2021-43546)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-0511)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-0843)&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-1097)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-1196)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-1529)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-1802)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-1919)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-2200)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-22737)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-22738)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-22739)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-22740)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-22741)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-22742)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-22743)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-22745)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-22747)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-22748)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-22754)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-22755)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-22756)Remote Agent, used in WebDriver, did not validate the Host or Origin headers. This could have allowed websites to connect back locally to the user&#39;s browser to control it. &lt;br&gt;*This bug only affected Firefox when WebDriver was enabled, which is not the default configuration.*. This vulnerability affects Firefox &lt; 97.(CVE-2022-22757)If a document created a sandboxed iframe without &lt;code&gt;allow-scripts&lt;/code&gt;, and subsequently appended an element to the iframe&#39;s document that e.g. had a JavaScript event handler - the event handler would have run despite the iframe&#39;s sandbox. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.(CVE-2022-22759)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-22760)Web-accessible extension pages (pages with a moz-extension:// scheme) were not correctly enforcing the frame-ancestors directive when it was used in the Web Extension&#39;s Content Security Policy. This vulnerability affects Firefox &lt; 97, Thunderbird &lt; 91.6, and Firefox ESR &lt; 91.6.(CVE-2022-22761)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-22763)regex is an implementation of regular expressions for the Rust language. The regex crate features built-in mitigations to prevent denial of service attacks caused by untrusted regexes, or untrusted input matched by trusted regexes. Those (tunable) mitigations already provide sane defaults to prevent attacks. This guarantee is documented and it&#39;s considered part of the crate&#39;s API. Unfortunately a bug was discovered in the mitigations designed to prevent untrusted regexes to take an arbitrary amount of time during parsing, and it&#39;s possible to craft regexes that bypass such mitigations. This makes it possible to perform denial of service attacks by sending specially crafted regexes to services accepting user-controlled, untrusted regexes. All versions of the regex crate before or equal to 1.5.4 are affected by this issue. The fix is include starting from regex 1.5.5. All users accepting user-controlled regexes are recommended to upgrade immediately to the latest version of the regex crate. Unfortunately there is no fixed set of problematic regexes, as there are practically infinite regexes that could be crafted to exploit this vulnerability. Because of this, it us not recommend to deny known problematic regexes.(CVE-2022-24713)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-26381)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-26382)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-26383)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-26384)In unusual circumstances, an individual thread may outlive the thread&#39;s manager during shutdown. This could have led to a use-after-free causing a potentially exploitable crash. This vulnerability affects Firefox &lt; 98.(CVE-2022-26385)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-26386)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-26387)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-26485)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-26486)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-28281)By using a link with &lt;code&gt;rel=&#34;localization&#34;&lt;/code&gt; a use-after-free could have been triggered by destroying an object during JavaScript execution and then referencing the object through a freed pointer, leading to a potential exploitable crash. This vulnerability affects Thunderbird &lt; 91.8, Firefox &lt; 99, and Firefox ESR &lt; 91.8.(CVE-2022-28282)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-28283)SVG&#39;s &lt;code&gt;&lt;use&gt;&lt;/code&gt; element could have been used to load unexpected content that could have executed script in certain circumstances. While the specification seems to allow this, other browsers do not, and web developers relied on this property for script security so gecko&#39;s implementation was aligned with theirs. This vulnerability affects Firefox &lt; 99.(CVE-2022-28284)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-28285)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-28286)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-28287)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-28289)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-29909)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-29911)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-29912)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-29914)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-29915)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-29916)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-29918)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-31736)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-31737)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-31738)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-31740)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-31741)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-31742)Firefox&#39;s HTML parser did not correctly interpret HTML comment tags, resulting in an incongruity with other browsers. This could have been used to escape HTML comments on pages that put user-controlled data in them. This vulnerability affects Firefox &lt; 101.(CVE-2022-31743)An attacker could have injected CSS into stylesheets accessible via internal URIs, such as resource:, and in doing so bypass a page&#39;s Content Security Policy. This vulnerability affects Firefox ESR &lt; 91.11, Thunderbird &lt; 102, Thunderbird &lt; 91.11, and Firefox &lt; 101.(CVE-2022-31744)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-31745)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-31748)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-3266)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-34468)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-34469)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-34470)When downloading an update for an addon, the downloaded addon update&#39;s version was not verified to match the version selected from the manifest. If the manifest had been tampered with on the server, an attacker could trick the browser into downgrading the addon to a prior version. This vulnerability affects Firefox &lt; 102.(CVE-2022-34471)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-34472)The HTML Sanitizer should have sanitized the &lt;code&gt;href&lt;/code&gt; attribute of SVG &lt;code&gt;&lt;use&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-34473)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-34474)SVG &lt;code&gt;&lt;use&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-34475)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-34476)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-34477)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-34479)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-34480)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-34481)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-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-34482. This vulnerability affects Firefox &lt; 102.(CVE-2022-34483)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-34484)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-34485)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-36318)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-36319)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-38472)A cross-origin iframe referencing an XSLT document would inherit the parent domain&#39;s permissions (such as microphone or camera access). This vulnerability affects Thunderbird &lt; 102.2, Thunderbird &lt; 91.13, Firefox ESR &lt; 91.13, Firefox ESR &lt; 102.2, and Firefox &lt; 104.(CVE-2022-38473)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-38477)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-38478)When injecting an HTML base element, some requests would ignore the CSP&#39;s base-uri settings and accept the injected element&#39;s base instead. This vulnerability affects Firefox ESR &lt; 102.3, Thunderbird &lt; 102.3, and Firefox &lt; 105.(CVE-2022-40956)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-40957)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-40958)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-40959)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-40960)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-40962)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-42928)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-45408)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-45409)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-45410)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-45411)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-45412)Keyboard events reference strings like &#34;KeyA&#34; that were at fixed, known, and widely-spread addresses. Cache-based timing attacks such as Prime+Probe could have possibly figured out which keys were being pressed. This vulnerability affects Firefox ESR &lt; 102.5, Thunderbird &lt; 102.5, and Firefox &lt; 107.(CVE-2022-45416)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-45418)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-45420)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-45421)An out of date library (libusrsctp) contained vulnerabilities that could potentially be exploited. This vulnerability affects Firefox &lt; 108.(CVE-2022-46871)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-46874)The executable file warning was not presented when downloading .atloc and .ftploc files, which can run commands on a user&#39;s computer. &lt;br&gt;*Note: This issue only affected Mac OS operating systems. Other operating systems are unaffected.*. This vulnerability affects Firefox &lt; 108, Firefox ESR &lt; 102.6, and Thunderbird &lt; 102.6.(CVE-2022-46875)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-46878)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-2022-46882)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-0767)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-1945)Due to the Firefox GTK wrapper code&#39;s use of text/plain for drag data and GTK treating all text/plain MIMEs containing file URLs as being dragged a website could arbitrarily read a file via a call to &lt;code&gt;DataTransfer.setData&lt;/code&gt;. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.(CVE-2023-23598)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-23599)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-23601)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-23602)Regular expressions used to filter out forbidden properties and values from style directives in calls to &lt;code&gt;console.log&lt;/code&gt; weren&#39;t accounting for external URLs. Data could then be potentially exfiltrated from the browser. This vulnerability affects Firefox &lt; 109, Thunderbird &lt; 102.7, and Firefox ESR &lt; 102.7.(CVE-2023-23603)The &lt;code&gt;Content-Security-Policy-Report-Only&lt;/code&gt; header could allow an attacker to leak a child iframe&#39;s unredacted URI when interaction with that iframe triggers a redirect. This vulnerability affects Firefox &lt; 110, Thunderbird &lt; 102.8, and Firefox ESR &lt; 102.8.(CVE-2023-25728)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-25729)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-25730)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-25732)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-25735)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-25737)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-25739)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-25742)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-25751)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-25752)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-28162)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-28164)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-28176)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-29533)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-29535)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-29536)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-29539)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-29541)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-29548)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-29550)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-32205)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-32206)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-32207)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-32211)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-32212)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-32213)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-32215)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-37201)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-37202)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-37207)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-37208)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-37211)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-4045)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-4046)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-4047)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-4048)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-4049)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-4050)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-4054)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-4055)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.(CVE-2023-4056)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-102.14.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-debugsource-102.14.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-debuginfo-102.14.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-102.14.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-debugsource-102.14.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-debuginfo-102.14.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1675</id>
          <title>An update for giflib is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39742" id="CVE-2023-39742" title="CVE-2023-39742" type="cve"></reference>
          </references>
          <description>giflib v5.2.1 was discovered to contain a segmentation fault via the component getarg.c.(CVE-2023-39742)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="giflib-devel" release="7.oe2203sp1" version="5.2.1">
                         <filename>giflib-devel-5.2.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="giflib-utils" release="7.oe2203sp1" version="5.2.1">
                         <filename>giflib-utils-5.2.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="giflib" release="7.oe2203sp1" version="5.2.1">
                         <filename>giflib-5.2.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="giflib-help" release="7.oe2203sp1" version="5.2.1">
                         <filename>giflib-help-5.2.1-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib-utils" release="7.oe2203sp1" version="5.2.1">
                         <filename>giflib-utils-5.2.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib-devel" release="7.oe2203sp1" version="5.2.1">
                         <filename>giflib-devel-5.2.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib" release="7.oe2203sp1" version="5.2.1">
                         <filename>giflib-5.2.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1676</id>
          <title>An update for pmix is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41915" id="CVE-2023-41915" title="CVE-2023-41915" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-41915)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pmix-devel" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-devel-4.2.6-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pmix-tools" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-tools-4.2.6-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pmix-debuginfo" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-debuginfo-4.2.6-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pmix-debugsource" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-debugsource-4.2.6-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pmix" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-4.2.6-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pmix-devel" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-devel-4.2.6-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pmix-debuginfo" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-debuginfo-4.2.6-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pmix-tools" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-tools-4.2.6-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pmix-debugsource" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-debugsource-4.2.6-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pmix" release="1.oe2203sp1" version="4.2.6">
                         <filename>pmix-4.2.6-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1677</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40217" id="CVE-2023-40217" title="CVE-2023-40217" type="cve"></reference>
          </references>
          <description>An issue was discovered in Python before 3.8.18, 3.9.x before 3.9.18, 3.10.x before 3.10.13, and 3.11.x before 3.11.5. It primarily affects servers (such as HTTP servers) that use TLS client authentication. If a TLS server-side socket is created, receives data into the socket buffer, and then is closed quickly, there is a brief window where the SSLSocket instance will detect the socket as &#34;not connected&#34; and won&#39;t initiate a handshake, but buffered data will still be readable from the socket buffer. This data will not be authenticated if the server-side TLS peer is expecting client certificate authentication, and is indistinguishable from valid TLS stream data. Data is limited in size to the amount that will fit in the buffer. (The TLS connection cannot directly be used for data exfiltration because the vulnerable code path requires that the connection be closed on initialization of the SSLSocket.)(CVE-2023-40217)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-debugsource" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-help-3.9.9-26.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="26.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1681</id>
          <title>An update for libwebp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4863" id="CVE-2023-4863" title="CVE-2023-4863" type="cve"></reference>
          </references>
          <description>Heap buffer overflow in WebP in Google Chrome prior to 116.0.5845.187 allowed a remote attacker to perform an out of bounds memory write via a crafted HTML page. (Chromium security severity: Critical)(CVE-2023-4863)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libwebp-debugsource" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-debugsource-1.2.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-devel" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-devel-1.2.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-tools" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-tools-1.2.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-1.2.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-debuginfo" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-debuginfo-1.2.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwebp-java" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-java-1.2.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libwebp-help" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-help-1.2.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-debugsource" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-debugsource-1.2.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-devel" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-devel-1.2.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-java" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-java-1.2.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-tools" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-tools-1.2.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-1.2.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwebp-debuginfo" release="4.oe2203sp1" version="1.2.1">
                         <filename>libwebp-debuginfo-1.2.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1682</id>
          <title>An update for grpc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4785" id="CVE-2023-4785" title="CVE-2023-4785" type="cve"></reference>
          </references>
          <description>Lack of error handling in the TCP server in Google&#39;s gRPC starting version 1.23 on posix-compatible platforms (ex. Linux) allows an attacker to cause a denial of service by initiating a significant number of connections with the server. Note that gRPC C++ Python, and Ruby are affected, but gRPC Java, and Go are NOT affected. (CVE-2023-4785)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="grpc-devel" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-devel-1.41.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grpc-debuginfo" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-debuginfo-1.41.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grpc-plugins" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-plugins-1.41.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-grpcio" release="6.oe2203sp1" version="1.41.1">
                         <filename>python3-grpcio-1.41.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grpc-debugsource" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-debugsource-1.41.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grpc" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-1.41.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grpc" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-1.41.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grpc-plugins" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-plugins-1.41.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grpc-devel" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-devel-1.41.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grpc-debuginfo" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-debuginfo-1.41.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grpc-debugsource" release="6.oe2203sp1" version="1.41.1">
                         <filename>grpc-debugsource-1.41.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-grpcio" release="6.oe2203sp1" version="1.41.1">
                         <filename>python3-grpcio-1.41.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1685</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1999" id="CVE-2023-1999" title="CVE-2023-1999" type="cve"></reference>
          </references>
          <description>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-1999)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox-debuginfo" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-debuginfo-102.14.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-102.14.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-debugsource-102.14.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-debuginfo-102.14.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-debugsource-102.14.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="1.oe2203sp1" version="102.14.0">
                         <filename>firefox-102.14.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1686</id>
          <title>An update for iSulad is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33635" id="CVE-2021-33635" title="CVE-2021-33635" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33636" id="CVE-2021-33636" title="CVE-2021-33636" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33637" id="CVE-2021-33637" title="CVE-2021-33637" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33638" id="CVE-2021-33638" title="CVE-2021-33638" type="cve"></reference>
          </references>
          <description>When malicious images are pulled by isula pull, attackers can execute arbitrary code.(CVE-2021-33635)When the isula load command is used to load malicious images, attackers can execute arbitrary code.(CVE-2021-33636)When the isula export command is used to export a container to an image and the container is controlled by an attacker, the attacker can escape the container.(CVE-2021-33637)When the isula cp command is used to copy files from a container to a host machine and the container is controlled by an attacker, the attacker can escape the container.(CVE-2021-33638)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iSulad-debuginfo" release="13.oe2203sp1" version="2.0.18">
                         <filename>iSulad-debuginfo-2.0.18-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iSulad" release="13.oe2203sp1" version="2.0.18">
                         <filename>iSulad-2.0.18-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iSulad-debugsource" release="13.oe2203sp1" version="2.0.18">
                         <filename>iSulad-debugsource-2.0.18-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iSulad" release="13.oe2203sp1" version="2.0.18">
                         <filename>iSulad-2.0.18-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iSulad-debuginfo" release="13.oe2203sp1" version="2.0.18">
                         <filename>iSulad-debuginfo-2.0.18-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iSulad-debugsource" release="13.oe2203sp1" version="2.0.18">
                         <filename>iSulad-debugsource-2.0.18-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1687</id>
          <title>An update for shadow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4641" id="CVE-2023-4641" title="CVE-2023-4641" type="cve"></reference>
          </references>
          <description>When gpasswd(1) asks for the new password, it asks twice (as is usual for confirming the new password).  Each of those 2 password prompts uses agetpass() to get the password.  If the second agetpass() fails, the first password, which has been copied into the &#39;static&#39; buffer &#39;pass&#39; via STRFCPY(), wasn&#39;t being zeroed.(CVE-2023-4641)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="shadow" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-4.9-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow-subid-devel" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-subid-devel-4.9-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow-debuginfo" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-debuginfo-4.9-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow-debugsource" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-debugsource-4.9-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="shadow-help" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-help-4.9-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-debuginfo" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-debuginfo-4.9-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-debugsource" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-debugsource-4.9-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-subid-devel" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-subid-devel-4.9-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow" release="13.oe2203sp1" version="4.9">
                         <filename>shadow-4.9-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1688</id>
          <title>An update for glibc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4806" id="CVE-2023-4806" title="CVE-2023-4806" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4813" id="CVE-2023-4813" title="CVE-2023-4813" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5156" id="CVE-2023-5156" title="CVE-2023-5156" type="cve"></reference>
          </references>
          <description>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-4806)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-4813)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.(CVE-2023-5156)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glibc-compat-2.17" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugutils" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss_modules" release="136.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nscd" release="136.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-common" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugsource" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-devel" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debuginfo" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-source" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-all-langpacks" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnsl" release="136.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-nss-devel" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-archive" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glibc-help" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-help-2.34-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-archive" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-nss-devel" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-source" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugsource" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nscd" release="136.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-common" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-devel" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-all-langpacks" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debuginfo" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugutils" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss_modules" release="136.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-compat-2.17" release="136.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnsl" release="136.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1689</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3341" id="CVE-2023-3341" title="CVE-2023-3341" type="cve"></reference>
          </references>
          <description>The code that processes control channel messages sent to `named` calls certain functions recursively during packet parsing. Recursion depth is only limited by the maximum accepted packet size; depending on the environment, this may cause the packet-parsing code to run out of available stack memory, causing `named` to terminate unexpectedly. Since each incoming control channel message is fully parsed before its contents are authenticated, exploiting this flaw does not require the attacker to hold a valid RNDC key; only network access to the control channel&#39;s configured TCP port is necessary.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.(CVE-2023-3341)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-license-9.16.23-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="20.oe2203sp1" version="9.16.23">
                         <filename>python3-bind-9.16.23-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="20.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1692</id>
          <title>An update for lcr is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33634" id="CVE-2021-33634" title="CVE-2021-33634" type="cve"></reference>
          </references>
          <description>Isula uses the lxc runtime (default) to run malicious images, which can cause DOS.(CVE-2021-33634)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="lcr-devel" release="7.oe2203sp1" version="2.0.9">
                         <filename>lcr-devel-2.0.9-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lcr-debugsource" release="7.oe2203sp1" version="2.0.9">
                         <filename>lcr-debugsource-2.0.9-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lcr-debuginfo" release="7.oe2203sp1" version="2.0.9">
                         <filename>lcr-debuginfo-2.0.9-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="lcr" release="7.oe2203sp1" version="2.0.9">
                         <filename>lcr-2.0.9-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lcr-devel" release="7.oe2203sp1" version="2.0.9">
                         <filename>lcr-devel-2.0.9-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lcr" release="7.oe2203sp1" version="2.0.9">
                         <filename>lcr-2.0.9-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lcr-debugsource" release="7.oe2203sp1" version="2.0.9">
                         <filename>lcr-debugsource-2.0.9-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="lcr-debuginfo" release="7.oe2203sp1" version="2.0.9">
                         <filename>lcr-debuginfo-2.0.9-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1698</id>
          <title>An update for python-gevent is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41419" id="CVE-2023-41419" title="CVE-2023-41419" type="cve"></reference>
          </references>
          <description>An issue in Gevent Gevent before version 23.9.1 allows a remote attacker to escalate privileges via a crafted script to the WSGIServer component.(CVE-2023-41419)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-gevent-debugsource" release="2.oe2203sp1" version="21.1.2">
                         <filename>python-gevent-debugsource-21.1.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-gevent-debuginfo" release="2.oe2203sp1" version="21.1.2">
                         <filename>python-gevent-debuginfo-21.1.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-gevent" release="2.oe2203sp1" version="21.1.2">
                         <filename>python3-gevent-21.1.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-gevent-help" release="2.oe2203sp1" version="21.1.2">
                         <filename>python-gevent-help-21.1.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-gevent" release="2.oe2203sp1" version="21.1.2">
                         <filename>python3-gevent-21.1.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-gevent-debuginfo" release="2.oe2203sp1" version="21.1.2">
                         <filename>python-gevent-debuginfo-21.1.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="21" arch="x86_64" name="python-gevent-debugsource" release="2.oe2203sp1" version="21.1.2">
                         <filename>python-gevent-debugsource-21.1.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1700</id>
          <title>An update for snappy-java is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43642" id="CVE-2023-43642" title="CVE-2023-43642" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-43642)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="snappy-java" release="3.oe2203sp1" version="1.1.2.4">
                         <filename>snappy-java-1.1.2.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="snappy-java-javadoc" release="3.oe2203sp1" version="1.1.2.4">
                         <filename>snappy-java-javadoc-1.1.2.4-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="snappy-java" release="3.oe2203sp1" version="1.1.2.4">
                         <filename>snappy-java-1.1.2.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1701</id>
          <title>An update for dsoftbus is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30362" id="CVE-2023-30362" title="CVE-2023-30362" type="cve"></reference>
          </references>
          <description>Buffer Overflow vulnerability in coap_send function in libcoap library 4.3.1-103-g52cfd56 fixed in 4.3.1-120-ge242200 allows attackers to obtain sensitive information via malformed pdu.(CVE-2023-30362)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="dsoftbus" release="5.oe2203sp1" version="1.0.0">
                         <filename>dsoftbus-1.0.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dsoftbus" release="5.oe2203sp1" version="1.0.0">
                         <filename>dsoftbus-1.0.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1704</id>
          <title>An update for cups is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-09-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4504" id="CVE-2023-4504" title="CVE-2023-4504" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-4504)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="cups-devel" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-libs" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-printerapp" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-client" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-ipptool" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-lpd" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debugsource" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="cups" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debuginfo" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-help" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-help-2.4.0-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-filesystem" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-filesystem-2.4.0-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-libs" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-printerapp" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="cups-client" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debugsource" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-devel" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-ipptool" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-lpd" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debuginfo" release="10.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1706</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5371" id="CVE-2023-5371" title="CVE-2023-5371" type="cve"></reference>
          </references>
          <description>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(CVE-2023-5371)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="4.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1707</id>
          <title>An update for python-urllib3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43804" id="CVE-2023-43804" title="CVE-2023-43804" type="cve"></reference>
          </references>
          <description>urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn&#39;t treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn&#39;t disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.(CVE-2023-43804)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-urllib3" release="5.oe2203sp1" version="1.26.12">
                         <filename>python3-urllib3-1.26.12-5.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1708</id>
          <title>An update for libX11 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43785" id="CVE-2023-43785" title="CVE-2023-43785" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43786" id="CVE-2023-43786" title="CVE-2023-43786" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43787" id="CVE-2023-43787" title="CVE-2023-43787" type="cve"></reference>
          </references>
          <description>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-43785)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-43786)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-43787)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libX11" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-1.7.2-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libX11-debugsource" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-debugsource-1.7.2-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libX11-debuginfo" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-debuginfo-1.7.2-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libX11-devel" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-devel-1.7.2-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libX11-help" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-help-1.7.2-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libX11-debuginfo" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-debuginfo-1.7.2-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libX11" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-1.7.2-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libX11-devel" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-devel-1.7.2-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libX11-debugsource" release="8.oe2203sp1" version="1.7.2">
                         <filename>libX11-debugsource-1.7.2-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1709</id>
          <title>An update for gstreamer1-plugins-bad-free is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40474" id="CVE-2023-40474" title="CVE-2023-40474" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40475" id="CVE-2023-40475" title="CVE-2023-40475" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40476" id="CVE-2023-40476" title="CVE-2023-40476" type="cve"></reference>
          </references>
          <description>VUL-0: CVE-2023-40474: gstreamer-plugins-bad: GStreamer MXF File Parsing Integer Overflow Remote Code Execution Vulnerability(CVE-2023-40474)VUL-0: CVE-2023-40475: gstreamer-plugins-bad: GStreamer MXF File Parsing Integer Overflow Remote Code Execution Vulnerability(CVE-2023-40475)VUL-0: CVE-2023-40476: gstreamer-plugins-bad: GStreamer H265 Parsing Stack-based Buffer Overflow Remote Code Execution Vulnerability(CVE-2023-40476)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gstreamer1-plugins-bad-free-devel" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-devel-1.16.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-bad-free" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-1.16.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-bad-free-debuginfo" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-debuginfo-1.16.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-bad-free-debugsource" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-debugsource-1.16.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-bad-free" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-1.16.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-bad-free-debugsource" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-debugsource-1.16.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-bad-free-debuginfo" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-debuginfo-1.16.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-bad-free-devel" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-devel-1.16.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1710</id>
          <title>An update for libXpm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43788" id="CVE-2023-43788" title="CVE-2023-43788" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43789" id="CVE-2023-43789" title="CVE-2023-43789" type="cve"></reference>
          </references>
          <description>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-43788)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.(CVE-2023-43789)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libXpm-debugsource" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-debugsource-3.5.13-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libXpm" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-3.5.13-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libXpm-debuginfo" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-debuginfo-3.5.13-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libXpm-devel" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-devel-3.5.13-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libXpm-help" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-help-3.5.13-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libXpm-devel" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-devel-3.5.13-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libXpm-debugsource" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-debugsource-3.5.13-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libXpm" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-3.5.13-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libXpm-debuginfo" release="5.oe2203sp1" version="3.5.13">
                         <filename>libXpm-debuginfo-3.5.13-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1711</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4573" id="CVE-2023-4573" title="CVE-2023-4573" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4574" id="CVE-2023-4574" title="CVE-2023-4574" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4575" id="CVE-2023-4575" title="CVE-2023-4575" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4581" id="CVE-2023-4581" title="CVE-2023-4581" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4584" id="CVE-2023-4584" title="CVE-2023-4584" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4863" id="CVE-2023-4863" title="CVE-2023-4863" type="cve"></reference>
          </references>
          <description>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-4573)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-4574)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-4575)Excel `.xll` add-in files did not have a blocklist entry in Firefox&#39;s executable blocklist which allowed them to be downloaded without any warning of their potential harm. This vulnerability affects Firefox &lt; 117, Firefox ESR &lt; 102.15, Firefox ESR &lt; 115.2, Thunderbird &lt; 102.15, and Thunderbird &lt; 115.2.(CVE-2023-4581)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-4584)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-4863)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox-debugsource" release="2.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox" release="2.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="2.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="2.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="2.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="2.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1716</id>
          <title>An update for mosquitto is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0809" id="CVE-2023-0809" title="CVE-2023-0809" type="cve"></reference>
          </references>
          <description>In Mosquitto before 2.0.16, excessive memory is allocated based on malicious initial packets that are not CONNECT packets.(CVE-2023-0809)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mosquitto-devel" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-devel-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debugsource" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debugsource-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debuginfo" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debuginfo-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debugsource" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debugsource-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debuginfo" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debuginfo-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-devel" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-devel-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1720</id>
          <title>An update for grub2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4692" id="CVE-2023-4692" title="CVE-2023-4692" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4693" id="CVE-2023-4693" title="CVE-2023-4693" type="cve"></reference>
          </references>
          <description>An out-of-bounds write flaw was found in grub2&#39;s NTFS filesystem driver. This issue may allow an attacker to present a specially crafted NTFS filesystem image, leading to grub&#39;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-4692)An out-of-bounds read flaw was found on grub2&#39;s NTFS filesystem driver. This issue may allow a physically present attacker to present a specially crafted NTFS file system image to read arbitrary memory locations. A successful attack allows sensitive data cached in memory or EFI variable values to be leaked, presenting a high Confidentiality risk.(CVE-2023-4693)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="grub2-tools-minimal" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-tools-minimal-2.06-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-debuginfo" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-debuginfo-2.06-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-tools-2.06-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64-cdboot" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-cdboot-2.06-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-extra" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-tools-extra-2.06-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-debugsource" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-debugsource-2.06-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-2.06-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-common" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-common-2.06-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-x64-modules" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-modules-2.06-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-pc-modules" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-pc-modules-2.06-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-aa64-modules" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-modules-2.06-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-ia32-modules" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-modules-2.06-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-help" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-help-2.06-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-efi" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-tools-efi-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debugsource" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-debugsource-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-tools-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32-cdboot" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-cdboot-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debuginfo" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-debuginfo-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64-cdboot" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-cdboot-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-pc" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-pc-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-extra" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-tools-extra-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-minimal" release="38.oe2203sp1" version="2.06">
                         <filename>grub2-tools-minimal-2.06-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1721</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5344" id="CVE-2023-5344" title="CVE-2023-5344" type="cve"></reference>
          </references>
          <description>Heap-based Buffer Overflow in GitHub repository vim/vim prior to 9.0.1969.(CVE-2023-5344)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="18.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="18.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="18.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="18.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="18.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="18.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="18.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="18.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="18.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="18.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="18.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="18.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="18.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1722</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43665" id="CVE-2023-43665" title="CVE-2023-43665" type="cve"></reference>
          </references>
          <description>An inefficient regular expression complexity was found in Django. The text truncator regular expressions exhibit linear backtracking complexity, which can be slow, leading to a potential denial of service, given certain HTML inputs.(CVE-2023-43665)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-Django" release="7.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-django-help" release="7.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-7.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1723</id>
          <title>An update for glibc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4911" id="CVE-2023-4911" title="CVE-2023-4911" type="cve"></reference>
          </references>
          <description>A buffer overflow was discovered in the GNU C Library&#39;s dynamic loader ld.so while processing the GLIBC_TUNABLES environment variable. This issue could allow a local attacker to use maliciously crafted GLIBC_TUNABLES environment variables when launching binaries with SUID permission to execute code with elevated privileges.(CVE-2023-4911)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glibc-locale-source" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-compat-2.17" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-archive" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-all-langpacks" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugutils" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-common" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss_modules" release="137.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debuginfo" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnsl" release="137.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-nss-devel" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-devel" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugsource" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nscd" release="137.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glibc-help" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-help-2.34-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debuginfo" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugsource" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-all-langpacks" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-devel" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss_modules" release="137.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nscd" release="137.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-nss-devel" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-source" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-compat-2.17" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-common" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnsl" release="137.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugutils" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-archive" release="137.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1730</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42753" id="CVE-2023-42753" title="CVE-2023-42753" type="cve"></reference>
          </references>
          <description>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-42753)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-source" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.51.0.130.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.51.0.130.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.51.0.130.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1732</id>
          <title>An update for openvswitch is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5366" id="CVE-2023-5366" title="CVE-2023-5366" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-5366)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openvswitch-devel" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-help" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-debugsource" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-debuginfo" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debuginfo" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debugsource" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-devel" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-help" release="5.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1733</id>
          <title>An update for ImageMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5341" id="CVE-2023-5341" title="CVE-2023-5341" type="cve"></reference>
          </references>
          <description>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(CVE-2023-5341)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="ImageMagick-devel" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debuginfo" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-help" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-debugsource" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-perl" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++-devel" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick-c++" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="ImageMagick" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-help" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-help-7.1.1.8-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-perl" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-perl-7.1.1.8-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-devel" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-devel-7.1.1.8-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-7.1.1.8-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debuginfo" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debuginfo-7.1.1.8-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-7.1.1.8-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-c++-devel" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-c++-devel-7.1.1.8-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="ImageMagick-debugsource" release="5.oe2203sp1" version="7.1.1.8">
                         <filename>ImageMagick-debugsource-7.1.1.8-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1735</id>
          <title>An update for gcc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4039" id="CVE-2023-4039" title="CVE-2023-4039" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-4039)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libquadmath" release="25.oe2203sp1" version="10.3.1">
                         <filename>libquadmath-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libasan-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libasan-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfortran-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgfortran-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libitm-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libitm-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc-gfortran" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-gfortran-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libobjc" release="25.oe2203sp1" version="10.3.1">
                         <filename>libobjc-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgccjit-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgccjit-devel-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libubsan" release="25.oe2203sp1" version="10.3.1">
                         <filename>libubsan-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtsan" release="25.oe2203sp1" version="10.3.1">
                         <filename>libtsan-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libstdc++-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libstdc++-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc-debugsource" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-debugsource-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libatomic-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libatomic-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libubsan-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libubsan-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblsan" release="25.oe2203sp1" version="10.3.1">
                         <filename>liblsan-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtsan-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libtsan-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libasan" release="25.oe2203sp1" version="10.3.1">
                         <filename>libasan-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libquadmath-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>libquadmath-devel-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblsan-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>liblsan-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libitm" release="25.oe2203sp1" version="10.3.1">
                         <filename>libitm-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc-gdb-plugin" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-gdb-plugin-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc-debuginfo" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-debuginfo-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libquadmath-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libquadmath-static-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgccjit" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgccjit-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libstdc++" release="25.oe2203sp1" version="10.3.1">
                         <filename>libstdc++-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc-objc" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-objc-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libatomic" release="25.oe2203sp1" version="10.3.1">
                         <filename>libatomic-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgomp" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgomp-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cpp" release="25.oe2203sp1" version="10.3.1">
                         <filename>cpp-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc-plugin-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-plugin-devel-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc-objc++" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-objc++-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libitm-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>libitm-devel-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gcc-c++" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-c++-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgcc" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgcc-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfortran" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgfortran-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libstdc++-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>libstdc++-devel-10.3.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libitm" release="25.oe2203sp1" version="10.3.1">
                         <filename>libitm-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libatomic-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libatomic-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtsan-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libtsan-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libitm-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>libitm-devel-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfortran" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgfortran-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libitm-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libitm-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc-plugin-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-plugin-devel-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgcc" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgcc-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libasan" release="25.oe2203sp1" version="10.3.1">
                         <filename>libasan-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc-debugsource" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-debugsource-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libstdc++-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>libstdc++-devel-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libstdc++" release="25.oe2203sp1" version="10.3.1">
                         <filename>libstdc++-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc-gdb-plugin" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-gdb-plugin-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libubsan" release="25.oe2203sp1" version="10.3.1">
                         <filename>libubsan-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libquadmath-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>libquadmath-devel-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libquadmath" release="25.oe2203sp1" version="10.3.1">
                         <filename>libquadmath-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc-objc" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-objc-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfortran-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgfortran-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc-c++" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-c++-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgomp" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgomp-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgccjit-devel" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgccjit-devel-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libobjc" release="25.oe2203sp1" version="10.3.1">
                         <filename>libobjc-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc-gfortran" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-gfortran-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cpp" release="25.oe2203sp1" version="10.3.1">
                         <filename>cpp-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgccjit" release="25.oe2203sp1" version="10.3.1">
                         <filename>libgccjit-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblsan" release="25.oe2203sp1" version="10.3.1">
                         <filename>liblsan-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libstdc++-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libstdc++-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc-objc++" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-objc++-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libasan-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libasan-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libatomic" release="25.oe2203sp1" version="10.3.1">
                         <filename>libatomic-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblsan-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>liblsan-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtsan" release="25.oe2203sp1" version="10.3.1">
                         <filename>libtsan-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gcc-debuginfo" release="25.oe2203sp1" version="10.3.1">
                         <filename>gcc-debuginfo-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libquadmath-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libquadmath-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libubsan-static" release="25.oe2203sp1" version="10.3.1">
                         <filename>libubsan-static-10.3.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1740</id>
          <title>An update for libvpx is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-13"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44488" id="CVE-2023-44488" title="CVE-2023-44488" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5217" id="CVE-2023-5217" title="CVE-2023-5217" type="cve"></reference>
          </references>
          <description>VP9 in libvpx before 1.13.1 mishandles widths, leading to a crash related to encoding.(CVE-2023-44488)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)(CVE-2023-5217)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libvpx" release="10.oe2203sp1" version="1.7.0">
                         <filename>libvpx-1.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx-debugsource" release="10.oe2203sp1" version="1.7.0">
                         <filename>libvpx-debugsource-1.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx-debuginfo" release="10.oe2203sp1" version="1.7.0">
                         <filename>libvpx-debuginfo-1.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx-devel" release="10.oe2203sp1" version="1.7.0">
                         <filename>libvpx-devel-1.7.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-debuginfo" release="10.oe2203sp1" version="1.7.0">
                         <filename>libvpx-debuginfo-1.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-devel" release="10.oe2203sp1" version="1.7.0">
                         <filename>libvpx-devel-1.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-debugsource" release="10.oe2203sp1" version="1.7.0">
                         <filename>libvpx-debugsource-1.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx" release="10.oe2203sp1" version="1.7.0">
                         <filename>libvpx-1.7.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1741</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42755" id="CVE-2023-42755" title="CVE-2023-42755" type="cve"></reference>
          </references>
          <description>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-42755)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.52.0.131.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.52.0.131.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.52.0.131.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1742</id>
          <title>An update for libxml2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45322" id="CVE-2023-45322" title="CVE-2023-45322" type="cve"></reference>
          </references>
          <description>** DISPUTED ** libxml2 through 2.11.5 has a use-after-free that can only occur after a certain memory allocation fails. This occurs in xmlUnlinkNode in tree.c. NOTE: the vendor&#39;s position is &#34;I don&#39;t think these issues are critical enough to warrant a CVE ID ... because an attacker typically can&#39;t control when memory allocations fail.&#34;(CVE-2023-45322)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-libxml2" release="9.oe2203sp1" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debugsource" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-2.9.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debuginfo" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-devel" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libxml2-help" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-help-2.9.14-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-2.9.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debugsource" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libxml2" release="9.oe2203sp1" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debuginfo" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-devel" release="9.oe2203sp1" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1745</id>
          <title>An update for libcue is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43641" id="CVE-2023-43641" title="CVE-2023-43641" type="cve"></reference>
          </references>
          <description>libcue provides an API for parsing and extracting data from CUE sheets. Versions 2.2.1 and prior are vulnerable to out-of-bounds array access. A user of the GNOME desktop environment can be exploited by downloading a cue sheet from a malicious webpage. Because the file is saved to `~/Downloads`, it is then automatically scanned by tracker-miners. And because it has a .cue filename extension, tracker-miners use libcue to parse the file. The file exploits the vulnerability in libcue to gain code execution. This issue is patched in version 2.3.0.(CVE-2023-43641)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libcue-devel" release="2.oe2203sp1" version="2.2.1">
                         <filename>libcue-devel-2.2.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcue" release="2.oe2203sp1" version="2.2.1">
                         <filename>libcue-2.2.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcue-debugsource" release="2.oe2203sp1" version="2.2.1">
                         <filename>libcue-debugsource-2.2.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcue-debuginfo" release="2.oe2203sp1" version="2.2.1">
                         <filename>libcue-debuginfo-2.2.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcue-devel" release="2.oe2203sp1" version="2.2.1">
                         <filename>libcue-devel-2.2.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcue-debugsource" release="2.oe2203sp1" version="2.2.1">
                         <filename>libcue-debugsource-2.2.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcue-debuginfo" release="2.oe2203sp1" version="2.2.1">
                         <filename>libcue-debuginfo-2.2.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcue" release="2.oe2203sp1" version="2.2.1">
                         <filename>libcue-2.2.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1749</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5441" id="CVE-2023-5441" title="CVE-2023-5441" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5535" id="CVE-2023-5535" title="CVE-2023-5535" type="cve"></reference>
          </references>
          <description>NULL Pointer Dereference in GitHub repository vim/vim prior to 20d161ace307e28690229b68584f2d84556f8960.(CVE-2023-5441)Use After Free in GitHub repository vim/vim prior to v9.0.2010.(CVE-2023-5535)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="19.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="19.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="19.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="19.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="19.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="19.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="19.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="19.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="19.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="19.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="19.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="19.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="19.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1750</id>
          <title>An update for mariadb is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5157" id="CVE-2023-5157" title="CVE-2023-5157" type="cve"></reference>
          </references>
          <description>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-2023-5157)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="mariadb-common" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-common-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debugsource" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-debugsource-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-oqgraph-engine" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-oqgraph-engine-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-errmsg" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-errmsg-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debuginfo" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-debuginfo-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-backup" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-backup-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-pam" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-pam-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-config" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-config-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-utils" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-utils-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-test" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-test-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-gssapi-server" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-gssapi-server-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-rocksdb-engine" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-rocksdb-engine-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-devel" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-devel-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-galera" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-galera-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded-devel" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-embedded-devel-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-embedded-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-test" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-test-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded-devel" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-embedded-devel-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-gssapi-server" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-gssapi-server-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-embedded-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debuginfo" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-debuginfo-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-backup" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-backup-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-oqgraph-engine" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-oqgraph-engine-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-config" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-config-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-common" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-common-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-pam" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-pam-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-errmsg" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-errmsg-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-utils" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-utils-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-devel" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-devel-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-galera" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-galera-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debugsource" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-debugsource-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1751</id>
          <title>An update for zlib is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45853" id="CVE-2023-45853" title="CVE-2023-45853" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-45853)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="zlib-devel" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-devel-1.2.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="minizip-devel" release="24.oe2203sp1" version="1.2.11">
                         <filename>minizip-devel-1.2.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="minizip" release="24.oe2203sp1" version="1.2.11">
                         <filename>minizip-1.2.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zlib-debuginfo" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-debuginfo-1.2.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zlib" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-1.2.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zlib-debugsource" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-debugsource-1.2.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="zlib-help" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-help-1.2.11-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zlib" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-1.2.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zlib-debugsource" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-debugsource-1.2.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zlib-devel" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-devel-1.2.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="minizip" release="24.oe2203sp1" version="1.2.11">
                         <filename>minizip-1.2.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zlib-debuginfo" release="24.oe2203sp1" version="1.2.11">
                         <filename>zlib-debuginfo-1.2.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="minizip-devel" release="24.oe2203sp1" version="1.2.11">
                         <filename>minizip-devel-1.2.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1756</id>
          <title>An update for samba is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3961" id="CVE-2023-3961" title="CVE-2023-3961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4091" id="CVE-2023-4091" title="CVE-2023-4091" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42669" id="CVE-2023-42669" title="CVE-2023-42669" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42670" id="CVE-2023-42670" title="CVE-2023-42670" type="cve"></reference>
          </references>
          <description>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-3961)A vulnerability was discovered in Samba, where the flaw allows SMB clients to truncate files, even with read-only permissions when the Samba VFS module &#34;acl_xattr&#34; is configured with &#34;acl_xattr:ignore system acls = yes&#34;. The SMB protocol allows opening files when the client requests read-only access but then implicitly truncates the opened file to 0 bytes if the client specifies a separate OVERWRITE create disposition request. The issue arises in configurations that bypass kernel file system permissions checks, relying solely on Samba&#39;s permissions.(CVE-2023-4091)A vulnerability was found in Samba&#39;s &#34;rpcecho&#34; development server, a non-Windows RPC server used to test Samba&#39;s DCE/RPC stack elements. This vulnerability stems from an RPC function that can be blocked indefinitely. The issue arises because the &#34;rpcecho&#34; service operates with only one worker in the main RPC task, allowing calls to the &#34;rpcecho&#34; server to be blocked for a specified time, causing service disruptions. This disruption is triggered by a &#34;sleep()&#34; call in the &#34;dcesrv_echo_TestSleep()&#34; function under specific conditions. Authenticated users or attackers can exploit this vulnerability to make calls to the &#34;rpcecho&#34; server, requesting it to block for a specified duration, effectively disrupting most services and leading to a complete denial of service on the AD DC. The DoS affects all other services as &#34;rpcecho&#34; runs in the main RPC task.(CVE-2023-42669)A flaw was found in Samba. It is susceptible to a vulnerability where multiple incompatible RPC listeners can be initiated, causing disruptions in the AD DC service. When Samba&#39;s RPC server experiences a high load or unresponsiveness, servers intended for non-AD DC purposes (for example, NT4-emulation &#34;classic DCs&#34;) can erroneously start and compete for the same unix domain sockets. This issue leads to partial query responses from the AD DC, causing issues such as &#34;The procedure number is out of range&#34; when using tools like Active Directory Users. This flaw allows an attacker to disrupt AD DC services.(CVE-2023-42670)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="samba-dc-bind-dlz" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-bind-dlz-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-modules" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-modules-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-krb5-locator" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-krb5-locator-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-common-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient-devel" release="8.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-devel-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-provision" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-provision-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient" release="8.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-winbind-clients" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-clients-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debuginfo" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-debuginfo-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-devel" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-devel-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-dc" release="8.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-dc-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ctdb" release="8.oe2203sp1" version="4.17.5">
                         <filename>ctdb-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-usershares" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-usershares-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-debugsource" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-debugsource-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-help" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-help-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-common-tools" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-common-tools-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc-libs" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-libs-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba" release="8.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libwbclient" release="8.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-dc" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmbclient-devel" release="8.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-devel-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-samba-test" release="8.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-test-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-client-libs" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-client-libs-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-krb5-printing" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-krb5-printing-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-test" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-test-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-libs" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-libs-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="samba-client" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-client-4.17.5-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="samba-pidl" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-pidl-4.17.5-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common-tools" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-common-tools-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient-devel" release="8.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-devel-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debuginfo" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-debuginfo-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba" release="8.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-client-libs" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-client-libs-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-krb5-printing" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-krb5-printing-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient-devel" release="8.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-devel-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-modules" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-modules-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-bind-dlz" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-bind-dlz-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libwbclient" release="8.oe2203sp1" version="4.17.5">
                         <filename>libwbclient-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmbclient" release="8.oe2203sp1" version="4.17.5">
                         <filename>libsmbclient-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ctdb" release="8.oe2203sp1" version="4.17.5">
                         <filename>ctdb-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-client" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-client-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-libs" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-libs-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-devel" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-devel-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-test" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-test-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-test" release="8.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-test-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-libs" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-libs-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-common" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-common-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-samba-dc" release="8.oe2203sp1" version="4.17.5">
                         <filename>python3-samba-dc-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc-provision" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-provision-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-krb5-locator" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-krb5-locator-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-dc" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-dc-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-usershares" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-usershares-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-debugsource" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-debugsource-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-winbind-clients" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-winbind-clients-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-vfs-glusterfs" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-vfs-glusterfs-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="samba-help" release="8.oe2203sp1" version="4.17.5">
                         <filename>samba-help-4.17.5-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1758</id>
          <title>An update for avahi is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38470" id="CVE-2023-38470" title="CVE-2023-38470" type="cve"></reference>
          </references>
          <description>A reachable assertion was found in avahi_escape_label.References:https://github.com/lathiat/avahi/issues/454(CVE-2023-38470)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="avahi-dnsconfd" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-dnsconfd-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-autoipd" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-autoipd-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-gobject" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-howl-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-devel-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-tools" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-tools-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-libs" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-libs-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-devel-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-libdns_sd-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-devel-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-glib" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-glib-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui-gtk3" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-ui-gtk3-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-debugsource" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-debugsource-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-ui-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-libdns_sd" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-ui-devel-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-gobject-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-devel-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-howl" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-glib-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-glib-devel-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-debuginfo" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-debuginfo-0.8-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="avahi-help" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-help-0.8-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-autoipd" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-autoipd-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-debugsource" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-debugsource-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-ui-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-dnsconfd" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-dnsconfd-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-glib-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-glib-devel-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-gobject-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-devel-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-howl-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-devel-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-libdns_sd-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-devel-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-debuginfo" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-debuginfo-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-devel-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-gobject" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui-gtk3" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-ui-gtk3-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-libs" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-libs-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-tools" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-tools-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-glib" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-glib-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-howl" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui-devel" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-ui-devel-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-libdns_sd" release="16.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-0.8-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1761</id>
          <title>An update for ceph is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-10-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43040" id="CVE-2023-43040" title="CVE-2023-43040" type="cve"></reference>
          </references>
          <description>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&#39;s form-data contains a key called &#39;bucket&#39; with a value matching the bucket&#39;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.(CVE-2023-43040)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="librgw-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>librgw-devel-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-resource-agents" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-resource-agents-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librados-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>librados-devel-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="cephfs-mirror" release="19.oe2203sp1" version="16.2.7">
                         <filename>cephfs-mirror-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-selinux" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-selinux-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-common" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-common-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="rbd-nbd" release="19.oe2203sp1" version="16.2.7">
                         <filename>rbd-nbd-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libcephsqlite" release="19.oe2203sp1" version="16.2.7">
                         <filename>libcephsqlite-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="rados-objclass-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>rados-objclass-devel-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libradosstriper1" release="19.oe2203sp1" version="16.2.7">
                         <filename>libradosstriper1-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libcephsqlite-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>libcephsqlite-devel-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-debugsource" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-debugsource-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-radosgw" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-radosgw-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-base" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-base-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libradospp-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>libradospp-devel-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-rgw" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-rgw-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libcephfs2" release="19.oe2203sp1" version="16.2.7">
                         <filename>libcephfs2-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-debuginfo" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-debuginfo-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libradosstriper-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>libradosstriper-devel-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-mgr" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-mgr-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-osd" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-osd-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-rbd" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-rbd-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-fuse" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-fuse-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-mds" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-mds-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-ceph-argparse" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-ceph-argparse-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librbd1" release="19.oe2203sp1" version="16.2.7">
                         <filename>librbd1-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librgw2" release="19.oe2203sp1" version="16.2.7">
                         <filename>librgw2-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-test" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-test-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-rados" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-rados-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-mon" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-mon-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="rbd-fuse" release="19.oe2203sp1" version="16.2.7">
                         <filename>rbd-fuse-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-cephfs" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-cephfs-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="python3-ceph-common" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-ceph-common-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="rbd-mirror" release="19.oe2203sp1" version="16.2.7">
                         <filename>rbd-mirror-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ceph-immutable-object-cache" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-immutable-object-cache-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librados2" release="19.oe2203sp1" version="16.2.7">
                         <filename>librados2-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libcephfs-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>libcephfs-devel-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="librbd-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>librbd-devel-16.2.7-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-ceph-common" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-ceph-common-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-mgr" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-mgr-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libradospp-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>libradospp-devel-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="rados-objclass-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>rados-objclass-devel-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-ceph-argparse" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-ceph-argparse-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-osd" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-osd-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librbd1" release="19.oe2203sp1" version="16.2.7">
                         <filename>librbd1-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libradosstriper1" release="19.oe2203sp1" version="16.2.7">
                         <filename>libradosstriper1-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librados-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>librados-devel-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="rbd-fuse" release="19.oe2203sp1" version="16.2.7">
                         <filename>rbd-fuse-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-debuginfo" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-debuginfo-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-test" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-test-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-rgw" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-rgw-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-cephfs" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-cephfs-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="rbd-nbd" release="19.oe2203sp1" version="16.2.7">
                         <filename>rbd-nbd-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-immutable-object-cache" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-immutable-object-cache-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-selinux" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-selinux-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-rbd" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-rbd-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librgw2" release="19.oe2203sp1" version="16.2.7">
                         <filename>librgw2-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="cephfs-mirror" release="19.oe2203sp1" version="16.2.7">
                         <filename>cephfs-mirror-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-debugsource" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-debugsource-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librbd-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>librbd-devel-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-resource-agents" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-resource-agents-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librados2" release="19.oe2203sp1" version="16.2.7">
                         <filename>librados2-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-fuse" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-fuse-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="rbd-mirror" release="19.oe2203sp1" version="16.2.7">
                         <filename>rbd-mirror-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libcephfs2" release="19.oe2203sp1" version="16.2.7">
                         <filename>libcephfs2-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libcephfs-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>libcephfs-devel-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-mon" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-mon-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-common" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-common-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-mds" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-mds-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-radosgw" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-radosgw-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="python3-rados" release="19.oe2203sp1" version="16.2.7">
                         <filename>python3-rados-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ceph-base" release="19.oe2203sp1" version="16.2.7">
                         <filename>ceph-base-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libcephsqlite-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>libcephsqlite-devel-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libradosstriper-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>libradosstriper-devel-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="librgw-devel" release="19.oe2203sp1" version="16.2.7">
                         <filename>librgw-devel-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libcephsqlite" release="19.oe2203sp1" version="16.2.7">
                         <filename>libcephsqlite-16.2.7-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1762</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38545" id="CVE-2023-38545" title="CVE-2023-38545" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38546" id="CVE-2023-38546" title="CVE-2023-38546" type="cve"></reference>
          </references>
          <description>This flaw makes curl overflow a heap based buffer in the SOCKS5 proxyhandshake.When curl is asked to pass along the host name to the SOCKS5 proxy to allowthat to resolve the address instead of it getting done by curl itself, themaximum length that host name can be is 255 bytes.If the host name is detected to be longer, curl switches to local nameresolving and instead passes on the resolved address only. Due to this bug,the local variable that means &#34;let the host resolve the name&#34; could get thewrong 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 theresolved address there.The target buffer being a heap based buffer, and the host name coming from theURL that curl has been told to operate with.(CVE-2023-38545)This flaw allows an attacker to insert cookies at will into a running programusing libcurl, if the specific series of conditions are met.libcurl performs transfers. In its API, an application creates &#34;easy handles&#34;that are the individual handles for single transfers.libcurl provides a function call that duplicates en easy handle called[curl_easy_duphandle](https://curl.se/libcurl/c/curl_easy_duphandle.html).If a transfer has cookies enabled when the handle is duplicated, thecookie-enable state is also cloned - but without cloning the actualcookies. If the source handle did not read any cookies from a specific file ondisk, the cloned version of the handle would instead store the file name as`none` (using the four ASCII letters, no quotes).Subsequent use of the cloned handle that does not explicitly set a source toload cookies from would then inadvertently load cookies from a file named`none` - if such a file exists and is readable in the current directory of theprogram using libcurl. And if using the correct file format of course.(CVE-2023-38546)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="curl-debuginfo" release="24.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl-devel" release="24.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl" release="24.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="24.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl" release="24.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="24.oe2203sp1" version="7.79.1">
                         <filename>curl-help-7.79.1-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="24.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="24.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="24.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="24.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="24.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1771</id>
          <title>An update for nghttp2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
          </references>
          <description>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-2023-44487)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libnghttp2-devel" release="5.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-devel-1.46.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nghttp2-debuginfo" release="5.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debuginfo-1.46.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nghttp2" release="5.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-1.46.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnghttp2" release="5.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-1.46.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nghttp2-debugsource" release="5.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debugsource-1.46.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="nghttp2-help" release="5.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-help-1.46.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2-debugsource" release="5.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debugsource-1.46.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2-debuginfo" release="5.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debuginfo-1.46.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnghttp2" release="5.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-1.46.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2" release="5.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-1.46.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnghttp2-devel" release="5.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-devel-1.46.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1773</id>
          <title>An update for mosquitto is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-10-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3592" id="CVE-2023-3592" title="CVE-2023-3592" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5632" id="CVE-2023-5632" title="CVE-2023-5632" type="cve"></reference>
          </references>
          <description>In Mosquitto before 2.0.16, a memory leak occurs when clients send v5 CONNECT packets with a will message that contains invalid property types.(CVE-2023-3592)In Eclipse Mosquito before and including 2.0.5, establishing a connection to the mosquitto server without sending data causes the EPOLLOUT event to be added, which results excessive CPU consumption. This could be used by a malicious actor to perform denial of service type attack. This issue is fixed in 2.0.6(CVE-2023-5632)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mosquitto-devel" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-devel-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debuginfo" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debuginfo-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mosquitto-debugsource" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debugsource-2.0.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debugsource" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debugsource-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-devel" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-devel-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mosquitto-debuginfo" release="1.oe2203sp1" version="2.0.16">
                         <filename>mosquitto-debuginfo-2.0.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1775</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5217" id="CVE-2023-5217" title="CVE-2023-5217" type="cve"></reference>
          </references>
          <description>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)(CVE-2023-5217)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox-debugsource" release="3.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="3.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox" release="3.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="3.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="3.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="3.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1776</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46846" id="CVE-2023-46846" title="CVE-2023-46846" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46847" id="CVE-2023-46847" title="CVE-2023-46847" type="cve"></reference>
          </references>
          <description>Description: Due to chunked decoder lenience Squid is vulnerable toRequest/Response smuggling attacks when parsing HTTP/1.1and ICAP messagesReference: https://github.com/squid-cache/squid/security/advisories/GHSA-j83v-w3p4-5cqhAffected versions: 2.6-6.3. Patched in 6.4.(CVE-2023-46846)Description: Due to a buffer overflow bug Squid is vulnerable to a Denial ofService attack against HTTP Digest AuthenticationReference: https://github.com/squid-cache/squid/security/advisories/GHSA-phqj-m8gv-cq4gAffected versions: 3.2.0.1-5.9, 6.0-6.3(CVE-2023-46847)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="18.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="18.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid" release="18.oe2203sp1" version="4.9">
                         <filename>squid-4.9-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="18.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="18.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="18.oe2203sp1" version="4.9">
                         <filename>squid-4.9-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1777</id>
          <title>An update for nginx is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
          </references>
          <description>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-2023-44487)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-xslt-filter" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-xslt-filter-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-perl" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-perl-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-devel" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-devel-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-image-filter" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-image-filter-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-debuginfo" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-debuginfo-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-mail" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-mail-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-debugsource" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-debugsource-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-stream" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-stream-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-1.21.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-all-modules" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-all-modules-1.21.5-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-filesystem" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-filesystem-1.21.5-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-help" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-help-1.21.5-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-perl" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-perl-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-image-filter" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-image-filter-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-debugsource" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-debugsource-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-debuginfo" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-debuginfo-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-stream" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-stream-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-mail" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-mail-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-xslt-filter" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-xslt-filter-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-devel" release="6.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-devel-1.21.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1778</id>
          <title>An update for activemq is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46604" id="CVE-2023-46604" title="CVE-2023-46604" type="cve"></reference>
          </references>
          <description>Apache ActiveMQ is vulnerable to Remote Code Execution.The vulnerability may allow a remote attacker with network access to a broker to run arbitrary shell commands by manipulating serialized class types in the OpenWire protocol to cause the broker to instantiate any class on the classpath. Users are recommended to upgrade to version 5.15.16, 5.16.7, 5.17.6, or 5.18.3, which fixes this issue.(CVE-2023-46604)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="activemq-javadoc" release="1.oe2203sp1" version="5.15.16">
                         <filename>activemq-javadoc-5.15.16-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="activemq" release="1.oe2203sp1" version="5.15.16">
                         <filename>activemq-5.15.16-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1782</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44033" id="CVE-2022-44033" title="CVE-2022-44033" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45919" id="CVE-2022-45919" title="CVE-2022-45919" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2593" id="CVE-2023-2593" title="CVE-2023-2593" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2898" id="CVE-2023-2898" title="CVE-2023-2898" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31083" id="CVE-2023-31083" title="CVE-2023-31083" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31085" id="CVE-2023-31085" title="CVE-2023-31085" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32246" id="CVE-2023-32246" title="CVE-2023-32246" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32254" id="CVE-2023-32254" title="CVE-2023-32254" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34324" id="CVE-2023-34324" title="CVE-2023-34324" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39189" id="CVE-2023-39189" title="CVE-2023-39189" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39192" id="CVE-2023-39192" title="CVE-2023-39192" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39193" id="CVE-2023-39193" title="CVE-2023-39193" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39194" id="CVE-2023-39194" title="CVE-2023-39194" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42754" id="CVE-2023-42754" title="CVE-2023-42754" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45862" id="CVE-2023-45862" title="CVE-2023-45862" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45863" id="CVE-2023-45863" title="CVE-2023-45863" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45871" id="CVE-2023-45871" title="CVE-2023-45871" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5717" id="CVE-2023-5717" title="CVE-2023-5717" type="cve"></reference>
          </references>
          <description>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-2022-44033)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-2022-45919)VUL-0: CVE-2023-2593: kernel: Linux Kernel ksmbd Memory Exhaustion Denial-of-Service Vulnerability(CVE-2023-2593)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-2898)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-31083)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-31085)VUL-0: CVE-2023-32246: kernel: Linux Kernel ksmbd RCU Callback Race Condition Local Privilege Escalation Vulnerability(CVE-2023-32246)A flaw was found in the Linux kernel&#39;s ksmbd, a high-performance in-kernel SMB server. The specific flaw exists within the processing of SMB2_TREE_DISCONNECT commands. The issue results from the lack of proper locking when performing operations on an object. An attacker can leverage this vulnerability to execute code in the context of the kernel.(CVE-2023-32254)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-34324)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-39189)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-39192)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-39193)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-39194)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-42754)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-2023-45862)An issue was discovered in lib/kobject.c in the Linux kernel before 6.2.3. With root access, an attacker can trigger a race condition that results in a fill_kobj_path out-of-bounds write.(CVE-2023-45863)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-45871)A heap out-of-bounds write vulnerability in the Linux kernel&#39;s Linux Kernel Performance Events (perf) component can be exploited to achieve local privilege escalation.If perf_read_group() is called while an event&#39;s sibling_list is smaller than its child&#39;s sibling_list, it can increment or write to memory locations outside of the allocated buffer.We recommend upgrading past commit 32671e3799ca2e4590773fd0e63aaa4229e50c06.(CVE-2023-5717)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.53.0.132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.53.0.132.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.53.0.132.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1784</id>
          <title>An update for traceroute is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46316" id="CVE-2023-46316" title="CVE-2023-46316" type="cve"></reference>
          </references>
          <description>In buc Traceroute 2.0.12 through 2.1.2 before 2.1.3, the wrapper scripts do not properly parse command lines.(CVE-2023-46316)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="3" arch="aarch64" name="traceroute-debugsource" release="2.oe2203sp1" version="2.1.2">
                         <filename>traceroute-debugsource-2.1.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="traceroute" release="2.oe2203sp1" version="2.1.2">
                         <filename>traceroute-2.1.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="traceroute-debuginfo" release="2.oe2203sp1" version="2.1.2">
                         <filename>traceroute-debuginfo-2.1.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="noarch" name="traceroute-help" release="2.oe2203sp1" version="2.1.2">
                         <filename>traceroute-help-2.1.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="traceroute-debuginfo" release="2.oe2203sp1" version="2.1.2">
                         <filename>traceroute-debuginfo-2.1.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="traceroute-debugsource" release="2.oe2203sp1" version="2.1.2">
                         <filename>traceroute-debugsource-2.1.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="traceroute" release="2.oe2203sp1" version="2.1.2">
                         <filename>traceroute-2.1.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1786</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3255" id="CVE-2023-3255" title="CVE-2023-3255" type="cve"></reference>
          </references>
          <description>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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-83.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-83.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="83.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-83.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1788</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45648" id="CVE-2023-45648" title="CVE-2023-45648" type="cve"></reference>
          </references>
          <description>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.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 fix the issue.(CVE-2023-45648)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="32.oe2203sp1" version="9.0.10">
                         <filename>tomcat-help-9.0.10-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat" release="32.oe2203sp1" version="9.0.10">
                         <filename>tomcat-9.0.10-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="32.oe2203sp1" version="9.0.10">
                         <filename>tomcat-jsvc-9.0.10-32.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1789</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39318" id="CVE-2023-39318" title="CVE-2023-39318" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39319" id="CVE-2023-39319" title="CVE-2023-39319" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39323" id="CVE-2023-39323" title="CVE-2023-39323" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
          </references>
          <description>The html/template package does not properly handle HTML-like &#34;&#34; comment tokens, nor hashbang &#34;#!&#34; comment tokens, in &lt;script&gt; contexts. This may cause the template parser to improperly interpret the contents of &lt;script&gt; contexts, causing actions to be improperly escaped. This may be leveraged to perform an XSS attack.(CVE-2023-39318)The html/template package does not apply the proper rules for handling occurrences of &#34;&lt;script&#34;, &#34;&lt;!--&#34;, and &#34;&lt;/script&#34; within JS literals in &lt;script&gt; contexts. This may cause the template parser to improperly consider script contexts to be terminated early, causing actions to be improperly escaped. This could be leveraged to perform an XSS attack.(CVE-2023-39319)Line directives (&#34;//line&#34;) can be used to bypass the restrictions on &#34;//go:cgo_&#34; directives, allowing blocked linker and compiler flags to be passed during compilation. This can result in unexpected execution of arbitrary code when running &#34;go build&#34;. The line directive requires the absolute path of the file in which the directive lives, which makes exploiting this issue significantly more complex.(CVE-2023-39323)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.(CVE-2023-39325)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="25.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="25.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="25.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="25.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1791</id>
          <title>An update for qt5-qtbase is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-33285" id="CVE-2023-33285" title="CVE-2023-33285" type="cve"></reference>
          </references>
          <description>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-33285)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtbase-devel" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-mysql" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-gui" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-private-devel" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-examples" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-odbc" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debugsource" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-postgresql" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-static" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debuginfo" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qt5-qtbase-common" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-common-5.15.2-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-examples" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-gui" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-private-devel" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-mysql" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debugsource" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-postgresql" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-static" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-odbc" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-devel" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debuginfo" release="11.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1792</id>
          <title>An update for sqlite-jdbc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32697" id="CVE-2023-32697" title="CVE-2023-32697" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-32697)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sqlite-jdbc" release="2.oe2203sp1" version="3.15.1">
                         <filename>sqlite-jdbc-3.15.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sqlite-jdbc-javadoc" release="2.oe2203sp1" version="3.15.1">
                         <filename>sqlite-jdbc-javadoc-3.15.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-jdbc" release="2.oe2203sp1" version="3.15.1">
                         <filename>sqlite-jdbc-3.15.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1793</id>
          <title>An update for avahi is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38471" id="CVE-2023-38471" title="CVE-2023-38471" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38472" id="CVE-2023-38472" title="CVE-2023-38472" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38473" id="CVE-2023-38473" title="CVE-2023-38473" type="cve"></reference>
          </references>
          <description>A vulnerability was found in Avahi. A reachable assertion exists in the dbus_set_host_name function.(CVE-2023-38471)A vulnerability was found in Avahi. A reachable assertion exists in the avahi_rdata_parse() function.(CVE-2023-38472)A vulnerability was found in Avahi. A reachable assertion exists in the avahi_alternative_host_name() function.(CVE-2023-38473)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="avahi-ui-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui-gtk3" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-gtk3-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-gobject" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-glib" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-glib-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-libs" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-libs-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-howl" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-autoipd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-autoipd-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-debugsource" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-debugsource-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-libdns_sd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-libdns_sd-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-dnsconfd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-dnsconfd-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-howl-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-gobject-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-tools" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-tools-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-glib-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-glib-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-debuginfo" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-debuginfo-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="avahi-help" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-help-0.8-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-libdns_sd-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-tools" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-tools-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-debugsource" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-debugsource-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-glib" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-glib-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-gobject" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-libdns_sd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui-gtk3" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-gtk3-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-libs" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-libs-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-howl" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-debuginfo" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-debuginfo-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-autoipd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-autoipd-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-howl-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-glib-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-glib-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-gobject-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-dnsconfd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-dnsconfd-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1794</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46724" id="CVE-2023-46724" title="CVE-2023-46724" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46728" id="CVE-2023-46728" title="CVE-2023-46728" type="cve"></reference>
          </references>
          <description> Squid is a caching proxy for the Web. Due to an Improper Validation of Specified Index bug, Squid versions 3.3.0.1 through 5.9 and 6.0 prior to 6.4 compiled using `--with-openssl` are vulnerable to a Denial of Service attack against SSL Certificate validation. This problem allows a remote server to perform Denial of Service against Squid Proxy by initiating a TLS Handshake with a specially crafted SSL Certificate in a server certificate chain. This attack is limited to HTTPS and SSL-Bump. This bug is fixed in Squid version 6.4. In addition, patches addressing this problem for the stable releases can be found in Squid&#39;s patch archives. Those who you use a prepackaged version of Squid should refer to the package vendor for availability information on updated packages.(CVE-2023-46724)Squid is a caching proxy for the Web supporting HTTP, HTTPS, FTP, and more. Due to a NULL pointer dereference bug Squid is vulnerable to a Denial of Service attack against Squid&#39;s Gopher gateway. The gopher protocol is always available and enabled in Squid prior to Squid 6.0.1. Responses triggering this bug are possible to be received from any gopher server, even those without malicious intent. Gopher support has been removed in Squid version 6.0.1. Users are advised to upgrade. Users unable to upgrade should reject all gopher URL requests.(CVE-2023-46728)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="squid" release="20.oe2203sp1" version="4.9">
                         <filename>squid-4.9-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="20.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="20.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="20.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="20.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="20.oe2203sp1" version="4.9">
                         <filename>squid-4.9-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1795</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5367" id="CVE-2023-5367" title="CVE-2023-5367" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5380" id="CVE-2023-5380" title="CVE-2023-5380" type="cve"></reference>
          </references>
          <description>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-5367)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-5380)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="23.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1796</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46246" id="CVE-2023-46246" title="CVE-2023-46246" type="cve"></reference>
          </references>
          <description>Vim is an improved version of the good old UNIX editor Vi. Heap-use-after-free in memory allocated in the function `ga_grow_inner` in in the file `src/alloc.c` at line 748, which is freed in the file `src/ex_docmd.c` in the function `do_cmdline` at line 1010 and then used again in `src/cmdhist.c` at line 759. When using the `:history` command, it&#39;s possible that the provided argument overflows the accepted value. Causing an Integer Overflow and potentially later an use-after-free. This vulnerability has been patched in version 9.0.2068.(CVE-2023-46246)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="21.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="21.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="21.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="21.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="21.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="21.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="21.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="21.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="21.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="21.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="21.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="21.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="21.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1798</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37453" id="CVE-2023-37453" title="CVE-2023-37453" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46813" id="CVE-2023-46813" title="CVE-2023-46813" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46862" id="CVE-2023-46862" title="CVE-2023-46862" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5178" id="CVE-2023-5178" title="CVE-2023-5178" type="cve"></reference>
          </references>
          <description>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-37453)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-2023-46813)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-46862)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 user to cause a use-after-free and double-free problem, which may permit remote code execution or lead to local privilege escalation in case that the attacker already has local privileges.(CVE-2023-5178)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-debugsource" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.54.0.133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.54.0.133.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.54.0.133.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1801</id>
          <title>An update for shim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40546" id="CVE-2023-40546" title="CVE-2023-40546" type="cve"></reference>
          </references>
          <description>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. Applying the patch 66e6579dbf921152f647a0c16da1d3b2f40861ca is able to eliminate this problem. The bugfix is ready for download at github.com.(CVE-2023-40546)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="shim" release="12.oe2203sp1" version="15.6">
                         <filename>shim-15.6-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debuginfo" release="12.oe2203sp1" version="15.6">
                         <filename>shim-debuginfo-15.6-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debugsource" release="12.oe2203sp1" version="15.6">
                         <filename>shim-debugsource-15.6-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="shim" release="12.oe2203sp1" version="15.6">
                         <filename>shim-15.6-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1804</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31122" id="CVE-2023-31122" title="CVE-2023-31122" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45802" id="CVE-2023-45802" title="CVE-2023-45802" type="cve"></reference>
          </references>
          <description>Out-of-bounds Read vulnerability in mod_macro of Apache HTTP Server.This issue affects Apache HTTP Server: through 2.4.57.(CVE-2023-31122)When a HTTP/2 stream was reset (RST frame) by a client, there was a time window were the request&#39;s memory resources were not reclaimed immediately. Instead, de-allocation was deferred to connection close. A client could send new requests and resets, keeping the connection busy and open and causing the memory footprint to keep on growing. On connection close, all resources were reclaimed, but the process might run out of memory before that.This was found by the reporter during testing of CVE-2023-44487 (HTTP/2 Rapid Reset Exploit) with their own test client. During &#34;normal&#34; HTTP/2 use, the probability to hit this bug is very low. The kept memory would not become noticeable before the connection closes or times out.Users are recommended to upgrade to version 2.4.58, which fixes the issue.(CVE-2023-45802)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="httpd-debugsource" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-help-2.4.51-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="20.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="20.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1809</id>
          <title>An update for qt is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34410" id="CVE-2023-34410" title="CVE-2023-34410" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-34410)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="qt" release="55.oe2203sp1" version="4.8.7">
                         <filename>qt-4.8.7-55.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt-devel" release="55.oe2203sp1" version="4.8.7">
                         <filename>qt-devel-4.8.7-55.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt-debuginfo" release="55.oe2203sp1" version="4.8.7">
                         <filename>qt-debuginfo-4.8.7-55.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt-debugsource" release="55.oe2203sp1" version="4.8.7">
                         <filename>qt-debugsource-4.8.7-55.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-debuginfo" release="55.oe2203sp1" version="4.8.7">
                         <filename>qt-debuginfo-4.8.7-55.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt" release="55.oe2203sp1" version="4.8.7">
                         <filename>qt-4.8.7-55.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-devel" release="55.oe2203sp1" version="4.8.7">
                         <filename>qt-devel-4.8.7-55.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-debugsource" release="55.oe2203sp1" version="4.8.7">
                         <filename>qt-debugsource-4.8.7-55.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1811</id>
          <title>An update for GraphicsMagick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21679" id="CVE-2020-21679" title="CVE-2020-21679" type="cve"></reference>
          </references>
          <description>Buffer Overflow vulnerability in WritePCXImage function in pcx.c in GraphicsMagick 1.4 allows remote attackers to cause a denial of service via converting of crafted image file to pcx format.(CVE-2020-21679)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="GraphicsMagick-debugsource" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-debugsource-1.3.41-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-debuginfo" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-debuginfo-1.3.41-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-devel" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-devel-1.3.41-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-c++" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-c++-1.3.41-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-perl" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-perl-1.3.41-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick-c++-devel" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-c++-devel-1.3.41-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="GraphicsMagick" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-1.3.41-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="GraphicsMagick-help" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-help-1.3.41-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-c++" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-c++-1.3.41-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-1.3.41-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-perl" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-perl-1.3.41-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-debuginfo" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-debuginfo-1.3.41-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-devel" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-devel-1.3.41-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-debugsource" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-debugsource-1.3.41-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="GraphicsMagick-c++-devel" release="1.oe2203sp1" version="1.3.41">
                         <filename>GraphicsMagick-c++-devel-1.3.41-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1812</id>
          <title>An update for avahi is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38469" id="CVE-2023-38469" title="CVE-2023-38469" type="cve"></reference>
          </references>
          <description>A vulnerability was found in Avahi, where a reachable assertion exists in avahi_dns_packet_append_record.(CVE-2023-38469)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="avahi-ui-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui-gtk3" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-gtk3-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-gobject" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-glib" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-glib-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-libs" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-libs-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-howl" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-autoipd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-autoipd-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-debugsource" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-debugsource-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-ui" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-libdns_sd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-libdns_sd-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-dnsconfd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-dnsconfd-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-compat-howl-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-gobject-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-tools" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-tools-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-glib-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-glib-devel-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="avahi-debuginfo" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-debuginfo-0.8-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="avahi-help" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-help-0.8-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-libdns_sd-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-tools" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-tools-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-debugsource" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-debugsource-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-glib" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-glib-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-gobject" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-libdns_sd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-libdns_sd-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-ui-gtk3" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-ui-gtk3-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-libs" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-libs-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-howl" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-debuginfo" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-debuginfo-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-autoipd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-autoipd-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-compat-howl-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-compat-howl-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-glib-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-glib-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-gobject-devel" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-gobject-devel-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avahi-dnsconfd" release="17.oe2203sp1" version="0.8">
                         <filename>avahi-dnsconfd-0.8-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1813</id>
          <title>An update for openjdk-1.8.0 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22067" id="CVE-2023-22067" title="CVE-2023-22067" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"></reference>
          </references>
          <description>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-22067)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-22081)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debugsource" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-src-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debuginfo" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.392.b08-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc-zip" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.392.b08-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-javadoc-1.8.0.392.b08-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debuginfo" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debugsource" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-src-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel-slowdebug" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk" release="2.oe2203sp1" version="1.8.0.392.b08">
                         <filename>java-1.8.0-openjdk-1.8.0.392.b08-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1815</id>
          <title>An update for openjdk-latest is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22025" id="CVE-2023-22025" title="CVE-2023-22025" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"></reference>
          </references>
          <description>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-22025)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-22081)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-demo" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-demo-21.0.0.35-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-headless" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-headless-21.0.0.35-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-devel" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-devel-21.0.0.35-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-src" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-src-21.0.0.35-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-javadoc-zip" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-javadoc-zip-21.0.0.35-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-21.0.0.35-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-javadoc" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-javadoc-21.0.0.35-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-latest-openjdk-jmods" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-jmods-21.0.0.35-1.rolling.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-demo" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-demo-21.0.0.35-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-21.0.0.35-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-src" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-src-21.0.0.35-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-jmods" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-jmods-21.0.0.35-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-javadoc" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-javadoc-21.0.0.35-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-javadoc-zip" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-javadoc-zip-21.0.0.35-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-devel" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-devel-21.0.0.35-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-latest-openjdk-headless" release="1.rolling.oe2203sp1" version="21.0.0.35">
                         <filename>java-latest-openjdk-headless-21.0.0.35-1.rolling.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1816</id>
          <title>An update for zziplib is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-18770" id="CVE-2020-18770" title="CVE-2020-18770" type="cve"></reference>
          </references>
          <description>An issue was discovered in function zzip_disk_entry_to_file_header in mmapped.c in zziplib 0.13.69, which will lead to a denial-of-service.(CVE-2020-18770)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="zziplib-debuginfo" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-debuginfo-0.13.71-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zziplib-devel" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-devel-0.13.71-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zziplib-debugsource" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-debugsource-0.13.71-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zziplib" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-0.13.71-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="zziplib-help" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-help-0.13.71-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zziplib-debuginfo" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-debuginfo-0.13.71-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zziplib-devel" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-devel-0.13.71-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zziplib-debugsource" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-debugsource-0.13.71-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zziplib" release="5.oe2203sp1" version="0.13.71">
                         <filename>zziplib-0.13.71-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1821</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5678" id="CVE-2023-5678" title="CVE-2023-5678" type="cve"></reference>
          </references>
          <description>Issue summary: Generating excessively long X9.42 DH keys or checkingexcessively long X9.42 DH keys or parameters may be very slow.Impact summary: 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 froman 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&#39;t make any of these checks, and is thereforevulnerable for excessively large P and Q parameters.Likewise, while DH_generate_key() performs a check for an excessively largeP, it doesn&#39;t check for an excessively large Q.An application that calls DH_generate_key() or DH_check_pub_key() andsupplies a key or parameters obtained from an untrusted source could bevulnerable to a Denial of Service attack.DH_generate_key() and DH_check_pub_key() are also called by a number ofother OpenSSL functions.  An application calling any of those otherfunctions may similarly be affected.  The other functions affected by thisare 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&#34;-pubcheck&#34; 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-2023-5678)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-29.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="29.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1824</id>
          <title>An update for skopeo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24534" id="CVE-2023-24534" title="CVE-2023-24534" type="cve"></reference>
          </references>
          <description>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-24534)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="skopeo-debugsource" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debugsource-1.5.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="skopeo" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-1.5.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="containers-common" release="3.oe2203sp1" version="1.5.2">
                         <filename>containers-common-1.5.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="skopeo-debuginfo" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debuginfo-1.5.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="containers-common" release="3.oe2203sp1" version="1.5.2">
                         <filename>containers-common-1.5.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo-debugsource" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debugsource-1.5.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-1.5.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo-debuginfo" release="3.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debuginfo-1.5.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1827</id>
          <title>An update for gdb is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39129" id="CVE-2023-39129" title="CVE-2023-39129" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-39129)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gdb-debuginfo" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-debuginfo-11.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-gdbserver" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-gdbserver-11.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-11.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-headless" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-headless-11.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-debugsource" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-debugsource-11.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gdb-help" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-help-11.1-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-headless" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-headless-11.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-debuginfo" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-debuginfo-11.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-debugsource" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-debugsource-11.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-gdbserver" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-gdbserver-11.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb" release="7.oe2203sp1" version="11.1">
                         <filename>gdb-11.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1830</id>
          <title>An update for mariadb is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0778" id="CVE-2022-0778" title="CVE-2022-0778" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32085" id="CVE-2022-32085" title="CVE-2022-32085" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32087" id="CVE-2022-32087" title="CVE-2022-32087" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32091" id="CVE-2022-32091" title="CVE-2022-32091" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47015" id="CVE-2022-47015" title="CVE-2022-47015" type="cve"></reference>
          </references>
          <description>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-0778)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-32085)MariaDB v10.2 to v10.7 was discovered to contain a segmentation fault via the component Item_args::walk_args.(CVE-2022-32087)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-32091)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-47015)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="mariadb-common" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-common-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-devel" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-devel-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-pam" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-pam-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-config" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-config-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-utils" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-utils-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-rocksdb-engine" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-rocksdb-engine-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-galera" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-galera-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-oqgraph-engine" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-oqgraph-engine-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debuginfo" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-debuginfo-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-gssapi-server" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-gssapi-server-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded-devel" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-embedded-devel-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-test" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-test-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-errmsg" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-errmsg-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-embedded-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debugsource" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-debugsource-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-backup" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-backup-10.5.22-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-embedded-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-common" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-common-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-test" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-test-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-backup" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-backup-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-oqgraph-engine" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-oqgraph-engine-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-errmsg" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-errmsg-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-config" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-config-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-utils" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-utils-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-galera" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-galera-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debuginfo" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-debuginfo-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-pam" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-pam-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-gssapi-server" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-gssapi-server-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-devel" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-devel-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-server-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debugsource" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-debugsource-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded-devel" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-embedded-devel-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb" release="1.oe2203sp1" version="10.5.22">
                         <filename>mariadb-10.5.22-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1832</id>
          <title>An update for open-vm-tools is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34058" id="CVE-2023-34058" title="CVE-2023-34058" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34059" id="CVE-2023-34059" title="CVE-2023-34059" type="cve"></reference>
          </references>
          <description>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-34058)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.(CVE-2023-34059)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="open-vm-tools-sdmp" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-sdmp-12.0.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-debuginfo" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-debuginfo-12.0.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-12.0.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-debugsource" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-debugsource-12.0.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-devel" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-devel-12.0.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-desktop" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-desktop-12.0.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="open-vm-tools-test" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-test-12.0.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-debuginfo" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-debuginfo-12.0.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-salt-minion" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-salt-minion-12.0.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-debugsource" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-debugsource-12.0.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-test" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-test-12.0.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-desktop" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-desktop-12.0.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-12.0.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-sdmp" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-sdmp-12.0.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="open-vm-tools-devel" release="4.oe2203sp1" version="12.0.5">
                         <filename>open-vm-tools-devel-12.0.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1834</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21509" id="CVE-2022-21509" title="CVE-2022-21509" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21515" id="CVE-2022-21515" title="CVE-2022-21515" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21517" id="CVE-2022-21517" title="CVE-2022-21517" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21522" id="CVE-2022-21522" title="CVE-2022-21522" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21525" id="CVE-2022-21525" title="CVE-2022-21525" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21526" id="CVE-2022-21526" title="CVE-2022-21526" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21527" id="CVE-2022-21527" title="CVE-2022-21527" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21528" id="CVE-2022-21528" title="CVE-2022-21528" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21529" id="CVE-2022-21529" title="CVE-2022-21529" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21530" id="CVE-2022-21530" title="CVE-2022-21530" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21531" id="CVE-2022-21531" title="CVE-2022-21531" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21534" id="CVE-2022-21534" title="CVE-2022-21534" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21537" id="CVE-2022-21537" title="CVE-2022-21537" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21538" id="CVE-2022-21538" title="CVE-2022-21538" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21539" id="CVE-2022-21539" title="CVE-2022-21539" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21547" id="CVE-2022-21547" title="CVE-2022-21547" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21553" id="CVE-2022-21553" title="CVE-2022-21553" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21569" id="CVE-2022-21569" title="CVE-2022-21569" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21592" id="CVE-2022-21592" title="CVE-2022-21592" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21594" id="CVE-2022-21594" title="CVE-2022-21594" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21599" id="CVE-2022-21599" title="CVE-2022-21599" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21604" id="CVE-2022-21604" title="CVE-2022-21604" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21608" id="CVE-2022-21608" title="CVE-2022-21608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21611" id="CVE-2022-21611" title="CVE-2022-21611" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21617" id="CVE-2022-21617" title="CVE-2022-21617" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21625" id="CVE-2022-21625" title="CVE-2022-21625" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21632" id="CVE-2022-21632" title="CVE-2022-21632" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21633" id="CVE-2022-21633" title="CVE-2022-21633" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21635" id="CVE-2022-21635" title="CVE-2022-21635" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21637" id="CVE-2022-21637" title="CVE-2022-21637" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21638" id="CVE-2022-21638" title="CVE-2022-21638" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21640" id="CVE-2022-21640" title="CVE-2022-21640" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21641" id="CVE-2022-21641" title="CVE-2022-21641" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32221" id="CVE-2022-32221" title="CVE-2022-32221" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39400" id="CVE-2022-39400" title="CVE-2022-39400" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39408" id="CVE-2022-39408" title="CVE-2022-39408" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39410" id="CVE-2022-39410" title="CVE-2022-39410" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43551" id="CVE-2022-43551" title="CVE-2022-43551" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21836" id="CVE-2023-21836" title="CVE-2023-21836" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21863" id="CVE-2023-21863" title="CVE-2023-21863" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21864" id="CVE-2023-21864" title="CVE-2023-21864" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21865" id="CVE-2023-21865" title="CVE-2023-21865" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21867" id="CVE-2023-21867" title="CVE-2023-21867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21868" id="CVE-2023-21868" title="CVE-2023-21868" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21869" id="CVE-2023-21869" title="CVE-2023-21869" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21870" id="CVE-2023-21870" title="CVE-2023-21870" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21871" id="CVE-2023-21871" title="CVE-2023-21871" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21872" id="CVE-2023-21872" title="CVE-2023-21872" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21873" id="CVE-2023-21873" title="CVE-2023-21873" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21874" id="CVE-2023-21874" title="CVE-2023-21874" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21875" id="CVE-2023-21875" title="CVE-2023-21875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21876" id="CVE-2023-21876" title="CVE-2023-21876" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21877" id="CVE-2023-21877" title="CVE-2023-21877" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21878" id="CVE-2023-21878" title="CVE-2023-21878" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21879" id="CVE-2023-21879" title="CVE-2023-21879" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21880" id="CVE-2023-21880" title="CVE-2023-21880" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21881" id="CVE-2023-21881" title="CVE-2023-21881" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21882" id="CVE-2023-21882" title="CVE-2023-21882" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21883" id="CVE-2023-21883" title="CVE-2023-21883" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21887" id="CVE-2023-21887" title="CVE-2023-21887" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21911" id="CVE-2023-21911" title="CVE-2023-21911" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21912" id="CVE-2023-21912" title="CVE-2023-21912" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21913" id="CVE-2023-21913" title="CVE-2023-21913" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21917" id="CVE-2023-21917" title="CVE-2023-21917" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21919" id="CVE-2023-21919" title="CVE-2023-21919" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21920" id="CVE-2023-21920" title="CVE-2023-21920" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21929" id="CVE-2023-21929" title="CVE-2023-21929" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21933" id="CVE-2023-21933" title="CVE-2023-21933" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21935" id="CVE-2023-21935" title="CVE-2023-21935" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21940" id="CVE-2023-21940" title="CVE-2023-21940" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21945" id="CVE-2023-21945" title="CVE-2023-21945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21946" id="CVE-2023-21946" title="CVE-2023-21946" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21947" id="CVE-2023-21947" title="CVE-2023-21947" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21953" id="CVE-2023-21953" title="CVE-2023-21953" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21955" id="CVE-2023-21955" title="CVE-2023-21955" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21962" id="CVE-2023-21962" title="CVE-2023-21962" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21963" id="CVE-2023-21963" title="CVE-2023-21963" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21966" id="CVE-2023-21966" title="CVE-2023-21966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21972" id="CVE-2023-21972" title="CVE-2023-21972" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21976" id="CVE-2023-21976" title="CVE-2023-21976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21977" id="CVE-2023-21977" title="CVE-2023-21977" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21980" id="CVE-2023-21980" title="CVE-2023-21980" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-21982" id="CVE-2023-21982" title="CVE-2023-21982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22005" id="CVE-2023-22005" title="CVE-2023-22005" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22007" id="CVE-2023-22007" title="CVE-2023-22007" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22008" id="CVE-2023-22008" title="CVE-2023-22008" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22015" id="CVE-2023-22015" title="CVE-2023-22015" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22026" id="CVE-2023-22026" title="CVE-2023-22026" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22028" id="CVE-2023-22028" title="CVE-2023-22028" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22032" id="CVE-2023-22032" title="CVE-2023-22032" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22033" id="CVE-2023-22033" title="CVE-2023-22033" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22038" id="CVE-2023-22038" title="CVE-2023-22038" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22046" id="CVE-2023-22046" title="CVE-2023-22046" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22048" id="CVE-2023-22048" title="CVE-2023-22048" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22053" id="CVE-2023-22053" title="CVE-2023-22053" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22054" id="CVE-2023-22054" title="CVE-2023-22054" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22056" id="CVE-2023-22056" title="CVE-2023-22056" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22057" id="CVE-2023-22057" title="CVE-2023-22057" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22058" id="CVE-2023-22058" title="CVE-2023-22058" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22059" id="CVE-2023-22059" title="CVE-2023-22059" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22064" id="CVE-2023-22064" title="CVE-2023-22064" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22065" id="CVE-2023-22065" title="CVE-2023-22065" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22066" id="CVE-2023-22066" title="CVE-2023-22066" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22068" id="CVE-2023-22068" title="CVE-2023-22068" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22070" id="CVE-2023-22070" title="CVE-2023-22070" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22078" id="CVE-2023-22078" title="CVE-2023-22078" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22079" id="CVE-2023-22079" title="CVE-2023-22079" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22084" id="CVE-2023-22084" title="CVE-2023-22084" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22092" id="CVE-2023-22092" title="CVE-2023-22092" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22097" id="CVE-2023-22097" title="CVE-2023-22097" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22103" id="CVE-2023-22103" title="CVE-2023-22103" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22104" id="CVE-2023-22104" title="CVE-2023-22104" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22110" id="CVE-2023-22110" title="CVE-2023-22110" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22111" id="CVE-2023-22111" title="CVE-2023-22111" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22112" id="CVE-2023-22112" title="CVE-2023-22112" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22113" id="CVE-2023-22113" title="CVE-2023-22113" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22114" id="CVE-2023-22114" title="CVE-2023-22114" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22115" id="CVE-2023-22115" title="CVE-2023-22115" type="cve"></reference>
          </references>
          <description>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-21509)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-21515)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-21517)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-21522)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-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-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 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-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-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. CVSS 3.1 Base Score 4.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-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-21531)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-21534)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-21537)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-21538)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-21539)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-21547)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-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 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: 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-21592)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-21594)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-21599)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: 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-21608)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-21611)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-21617)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-21625)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-21632)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-21633)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-21635)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-21637)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.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.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-21641)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-2022-32221)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-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 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-39410)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-43551)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-21836)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-21863)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-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-21865)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-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 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-21868)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-21869)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-21870)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-21871)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-21872)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: 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-21874)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-21875)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-21876)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-21877)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-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-2023-21879)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-21880)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-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 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-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 ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.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: 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-21887)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-21911)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-21912)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-21913)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-21917)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-21919)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-21920)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-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. CVSS 3.1 Base Score 4.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: 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-21935)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-21940)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-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 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-21946)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-21947)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-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-21955)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-21962)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-21963)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-21966)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-21972)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-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-21977)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-21980)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: 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-22005)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-22007)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-22008)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-22026)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-22028)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-22032)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-22033)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-22038)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-22046)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-22048)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-22053)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-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-22056)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-22057)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-22058)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-22059)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-22064)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: 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-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-22068)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-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-22078)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-22079)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-22084)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: 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: 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-22103)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-22104)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-22110)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-22111)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-22112)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-22113)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-22114)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-22115)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-common-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-test-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-libs-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-help-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-errmsg-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-debuginfo-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-devel-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-debugsource-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-config-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-server-8.0.35-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-server-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-errmsg-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-debugsource-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-help-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-libs-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-common-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-debuginfo-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-config-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-test-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-devel-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp1" version="8.0.35">
                         <filename>mysql-8.0.35-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1840</id>
          <title>An update for python-urllib3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45803" id="CVE-2023-45803" title="CVE-2023-45803" type="cve"></reference>
          </references>
          <description>urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn&#39;t remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren&#39;t putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn&#39;t exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren&#39;t expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.(CVE-2023-45803)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-urllib3" release="6.oe2203sp1" version="1.26.12">
                         <filename>python3-urllib3-1.26.12-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1844</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45884" id="CVE-2022-45884" title="CVE-2022-45884" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3327" id="CVE-2023-3327" title="CVE-2023-3327" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39198" id="CVE-2023-39198" title="CVE-2023-39198" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4623" id="CVE-2023-4623" title="CVE-2023-4623" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5197" id="CVE-2023-5197" title="CVE-2023-5197" type="cve"></reference>
          </references>
          <description>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-45884)Rejected reason: DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2023-35823. Reason: This candidate is a reservation duplicate of CVE-2023-35823. Notes: All CVE users should reference CVE-2023-35823 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.(CVE-2023-3327)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.(CVE-2023-39198)A use-after-free vulnerability in the Linux kernel&#39;s net/sched: sch_hfsc (HFSC qdisc traffic control) component can be exploited to achieve local privilege escalation.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.We recommend upgrading past commit b3d26c5702c7d6c45456326e56d2ccf3f103e60f.(CVE-2023-4623)A use-after-free vulnerability in the Linux kernel&#39;s netfilter: nf_tables component can be exploited to achieve local privilege escalation.Addition and removal of rules from chain bindings within the same transaction causes leads to use-after-free.We recommend upgrading past commit f15f29fd4779be8a418b66e9d52979bb6d6c2325.(CVE-2023-5197)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.55.0.134.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.55.0.134.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.55.0.134.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1846</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46695" id="CVE-2023-46695" title="CVE-2023-46695" type="cve"></reference>
          </references>
          <description>An issue was discovered in Django 3.2 before 3.2.23, 4.1 before 4.1.13, and 4.2 before 4.2.7. The NFKC normalization is slow on Windows. As a consequence, django.contrib.auth.forms.UsernameField is subject to a potential DoS (denial of service) attack via certain inputs with a very large number of Unicode characters.(CVE-2023-46695)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-Django" release="8.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-django-help" release="8.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-8.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1847</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6175" id="CVE-2023-6175" title="CVE-2023-6175" type="cve"></reference>
          </references>
          <description>A heap-based buffer overflow was found in Wireshark&#39;s NetScreen file parser. This issue may allow local arbitrary code execution via a crafted capture file.(CVE-2023-6175)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="5.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1848</id>
          <title>An update for openjdk-11 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22081" id="CVE-2023-22081" title="CVE-2023-22081" type="cve"></reference>
          </references>
          <description>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-22081)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debugsource" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-debugsource-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-headless-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc-zip" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-javadoc-zip-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-slowdebug-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-jmods-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-src-slowdebug-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-javadoc-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debuginfo" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-debuginfo-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-demo-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-devel-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-src-11.0.21.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-src-slowdebug-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-headless-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-src-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debugsource" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-debugsource-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc-zip" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-javadoc-zip-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debuginfo" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-debuginfo-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-javadoc-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-jmods-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-devel-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-slowdebug-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel-slowdebug" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo" release="1.oe2203sp1" version="11.0.21.9">
                         <filename>java-11-openjdk-demo-11.0.21.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1851</id>
          <title>An update for shadow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-11-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2013-4235" id="CVE-2013-4235" title="CVE-2013-4235" type="cve"></reference>
          </references>
          <description>shadow: TOCTOU (time-of-check time-of-use) race condition when copying and removing directory trees(CVE-2013-4235)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="shadow-debuginfo" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-debuginfo-4.9-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-4.9-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow-subid-devel" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-subid-devel-4.9-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="shadow-debugsource" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-debugsource-4.9-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="shadow-help" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-help-4.9-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-debuginfo" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-debuginfo-4.9-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-debugsource" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-debugsource-4.9-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-4.9-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="shadow-subid-devel" release="14.oe2203sp1" version="4.9">
                         <filename>shadow-subid-devel-4.9-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1854</id>
          <title>An update for python-aiohttp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-11-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47641" id="CVE-2023-47641" title="CVE-2023-47641" type="cve"></reference>
          </references>
          <description>aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Affected versions of aiohttp have a security vulnerability regarding the inconsistent interpretation of the http protocol. HTTP/1.1 is a persistent protocol, if both Content-Length(CL) and Transfer-Encoding(TE) header values are present it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect an attacker could combine it to redirect random users to another website and log the request. This vulnerability has been addressed in release 3.8.0 of aiohttp. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-47641)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-aiohttp-help" release="3.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-debuginfo" release="3.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-debugsource" release="3.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-aiohttp" release="3.oe2203sp1" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debuginfo" release="3.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-aiohttp" release="3.oe2203sp1" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-help" release="3.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debugsource" release="3.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1855</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23583" id="CVE-2023-23583" title="CVE-2023-23583" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-23583)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="42.oe2203sp1" version="2.1">
                         <filename>microcode_ctl-2.1-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1856</id>
          <title>An update for python-pillow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-11-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44271" id="CVE-2023-44271" title="CVE-2023-44271" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-44271)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-pillow-devel" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-qt" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debuginfo" release="4.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debugsource" release="4.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-tk" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pillow-help" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-help-9.0.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debuginfo" release="4.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debugsource" release="4.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-qt" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-devel" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-tk" release="4.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1857</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-11-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6228" id="CVE-2023-6228" title="CVE-2023-6228" type="cve"></reference>
          </references>
          <description>An issue was found in the tiffcp utility distributed by the libtiff package. Processing a crafted TIFF file may cause a heap-based buffer overflow, resulting in an application crash.Reference:https://gitlab.com/libtiff/libtiff/-/issues/606(CVE-2023-6228)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-tools" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="34.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1860</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39197" id="CVE-2023-39197" title="CVE-2023-39197" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6176" id="CVE-2023-6176" title="CVE-2023-6176" type="cve"></reference>
          </references>
          <description>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-39197)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-6176)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.56.0.135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-source" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.56.0.135.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.56.0.135.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1863</id>
          <title>An update for perl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-12-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47038" id="CVE-2023-47038" title="CVE-2023-47038" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-47038)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="4" arch="aarch64" name="perl-libs" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debugsource" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debuginfo" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-devel" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="noarch" name="perl-help" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-help-5.34.0-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debugsource" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debuginfo" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-devel" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-libs" release="10.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1867</id>
          <title>An update for gnutls is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5981" id="CVE-2023-5981" title="CVE-2023-5981" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-5981)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnutls-debugsource" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-devel" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debuginfo" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-utils" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnutls-help" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-help-3.7.2-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-utils" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debugsource" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-devel" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debuginfo" release="10.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1871</id>
          <title>An update for gdb is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39130" id="CVE-2023-39130" title="CVE-2023-39130" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-39130)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gdb" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-11.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-headless" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-headless-11.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-debuginfo" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-debuginfo-11.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-debugsource" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-debugsource-11.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdb-gdbserver" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-gdbserver-11.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gdb-help" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-help-11.1-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-debugsource" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-debugsource-11.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-gdbserver" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-gdbserver-11.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-11.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-debuginfo" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-debuginfo-11.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdb-headless" release="8.oe2203sp1" version="11.1">
                         <filename>gdb-headless-11.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1873</id>
          <title>An update for optipng is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43907" id="CVE-2023-43907" title="CVE-2023-43907" type="cve"></reference>
          </references>
          <description>OptiPNG v0.7.7 was discovered to contain a global buffer overflow via the &#39;buffer&#39; variable at gifread.c.(CVE-2023-43907)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="optipng-debugsource" release="1.oe2203sp1" version="0.7.8">
                         <filename>optipng-debugsource-0.7.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="optipng" release="1.oe2203sp1" version="0.7.8">
                         <filename>optipng-0.7.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="optipng-debuginfo" release="1.oe2203sp1" version="0.7.8">
                         <filename>optipng-debuginfo-0.7.8-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="optipng-debugsource" release="1.oe2203sp1" version="0.7.8">
                         <filename>optipng-debugsource-0.7.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="optipng-debuginfo" release="1.oe2203sp1" version="0.7.8">
                         <filename>optipng-debuginfo-0.7.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="optipng" release="1.oe2203sp1" version="0.7.8">
                         <filename>optipng-0.7.8-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1876</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-12-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48231" id="CVE-2023-48231" title="CVE-2023-48231" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48233" id="CVE-2023-48233" title="CVE-2023-48233" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48234" id="CVE-2023-48234" title="CVE-2023-48234" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48235" id="CVE-2023-48235" title="CVE-2023-48235" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48236" id="CVE-2023-48236" title="CVE-2023-48236" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48237" id="CVE-2023-48237" title="CVE-2023-48237" type="cve"></reference>
          </references>
          <description>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-48231)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-48233)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-48234)Vim is an open source command line text editor. When parsing relative ex addresses one may unintentionally cause anoverflow. 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-48235)Vim is an open source command line text editor. When using the z= command, the user may overflow the count with values largerthan 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-48236)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.(CVE-2023-48237)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="22.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="22.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="22.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="22.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="22.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="22.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="22.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="22.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="22.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="22.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="22.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="22.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="22.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1877</id>
          <title>An update for qt is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37369" id="CVE-2023-37369" title="CVE-2023-37369" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38197" id="CVE-2023-38197" title="CVE-2023-38197" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43114" id="CVE-2023-43114" title="CVE-2023-43114" type="cve"></reference>
          </references>
          <description>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-37369)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-38197)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-43114)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="qt-devel" release="58.oe2203sp1" version="4.8.7">
                         <filename>qt-devel-4.8.7-58.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt-debugsource" release="58.oe2203sp1" version="4.8.7">
                         <filename>qt-debugsource-4.8.7-58.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt-debuginfo" release="58.oe2203sp1" version="4.8.7">
                         <filename>qt-debuginfo-4.8.7-58.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="qt" release="58.oe2203sp1" version="4.8.7">
                         <filename>qt-4.8.7-58.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-debuginfo" release="58.oe2203sp1" version="4.8.7">
                         <filename>qt-debuginfo-4.8.7-58.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-debugsource" release="58.oe2203sp1" version="4.8.7">
                         <filename>qt-debugsource-4.8.7-58.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt" release="58.oe2203sp1" version="4.8.7">
                         <filename>qt-4.8.7-58.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="qt-devel" release="58.oe2203sp1" version="4.8.7">
                         <filename>qt-devel-4.8.7-58.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1882</id>
          <title>An update for apache-commons-net is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-37533" id="CVE-2021-37533" title="CVE-2021-37533" type="cve"></reference>
          </references>
          <description>Prior to Apache Commons Net 3.9.0, Net&#39;s FTP client trusts the host from PASV response by default. A malicious server can redirect the Commons Net code to use a different host, but the user has to connect to the malicious server in the first place. This may lead to leakage of information about services running on the private network of the client. The default in version 3.9.0 is now false to ignore such hosts, as cURL does. See https://issues.apache.org/jira/browse/NET-711.(CVE-2021-37533)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="apache-commons-net" release="7.oe2203sp1" version="3.6">
                         <filename>apache-commons-net-3.6-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="apache-commons-net-help" release="7.oe2203sp1" version="3.6">
                         <filename>apache-commons-net-help-3.6-7.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1887</id>
          <title>An update for python-cryptography is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-12-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49083" id="CVE-2023-49083" title="CVE-2023-49083" type="cve"></reference>
          </references>
          <description>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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-cryptography" release="6.oe2203sp1" version="36.0.1">
                         <filename>python3-cryptography-36.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-cryptography-debuginfo" release="6.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-debuginfo-36.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-cryptography-debugsource" release="6.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-debugsource-36.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-cryptography-help" release="6.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-help-36.0.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-cryptography-debuginfo" release="6.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-debuginfo-36.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-cryptography-debugsource" release="6.oe2203sp1" version="36.0.1">
                         <filename>python-cryptography-debugsource-36.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-cryptography" release="6.oe2203sp1" version="36.0.1">
                         <filename>python3-cryptography-36.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1889</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1193" id="CVE-2023-1193" title="CVE-2023-1193" type="cve"></reference>
          </references>
          <description>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-1193)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.57.0.136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.57.0.136.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.57.0.136.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1893</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6277" id="CVE-2023-6277" title="CVE-2023-6277" type="cve"></reference>
          </references>
          <description>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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-debuginfo" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-tools" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-36.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="36.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1896</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1544" id="CVE-2023-1544" title="CVE-2023-1544" type="cve"></reference>
          </references>
          <description>A flaw was found in the QEMU implementation of VMWare&#39;s paravirtual RDMA device. This flaw allows a crafted guest driver to allocate and initialize a huge number of page tables to be used as a ring of descriptors for CQ and async events, potentially leading to an out-of-bounds read and crash of QEMU.(CVE-2023-1544)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-86.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-86.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="86.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-86.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1898</id>
          <title>An update for freeimage is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21427" id="CVE-2020-21427" title="CVE-2020-21427" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-21428" id="CVE-2020-21428" title="CVE-2020-21428" type="cve"></reference>
          </references>
          <description>Buffer Overflow vulnerability in function LoadPixelDataRLE8 in PluginBMP.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file.(CVE-2020-21427)Buffer Overflow vulnerability in function LoadRGB in PluginDDS.cpp in FreeImage 3.18.0 allows remote attackers to run arbitrary code and cause other impacts via crafted image file.(CVE-2020-21428)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="freeimage-debugsource" release="9.oe2203sp1" version="3.18.0">
                         <filename>freeimage-debugsource-3.18.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeimage-debuginfo" release="9.oe2203sp1" version="3.18.0">
                         <filename>freeimage-debuginfo-3.18.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeimage" release="9.oe2203sp1" version="3.18.0">
                         <filename>freeimage-3.18.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeimage-devel" release="9.oe2203sp1" version="3.18.0">
                         <filename>freeimage-devel-3.18.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeimage" release="9.oe2203sp1" version="3.18.0">
                         <filename>freeimage-3.18.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeimage-debuginfo" release="9.oe2203sp1" version="3.18.0">
                         <filename>freeimage-debuginfo-3.18.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeimage-debugsource" release="9.oe2203sp1" version="3.18.0">
                         <filename>freeimage-debugsource-3.18.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeimage-devel" release="9.oe2203sp1" version="3.18.0">
                         <filename>freeimage-devel-3.18.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1899</id>
          <title>An update for arm-trusted-firmware is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-47630" id="CVE-2022-47630" title="CVE-2022-47630" type="cve"></reference>
          </references>
          <description>Trusted Firmware-A through 2.8 has an out-of-bounds read in the X.509 parser for parsing boot certificates. This affects downstream use of get_ext and auth_nvctr. Attackers might be able to trigger dangerous read side effects or obtain sensitive information about microarchitectural state.(CVE-2022-47630)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="arm-trusted-firmware-armv8" release="3.oe2203sp1" version="2.3">
                         <filename>arm-trusted-firmware-armv8-2.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1900</id>
          <title>An update for python-aiohttp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49081" id="CVE-2023-49081" title="CVE-2023-49081" type="cve"></reference>
          </references>
          <description>aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Improper validation made it possible for an attacker to modify the HTTP request (e.g. to insert a new header) or create a new HTTP request if the attacker controls the HTTP version. The vulnerability only occurs if the attacker can control the HTTP version of the request. This issue has been patched in version 3.9.0.(CVE-2023-49081)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-aiohttp" release="4.oe2203sp1" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-help" release="4.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-debuginfo" release="4.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-aiohttp-debugsource" release="4.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-aiohttp" release="4.oe2203sp1" version="3.7.4">
                         <filename>python3-aiohttp-3.7.4-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debuginfo" release="4.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-debuginfo-3.7.4-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-help" release="4.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-help-3.7.4-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-aiohttp-debugsource" release="4.oe2203sp1" version="3.7.4">
                         <filename>python-aiohttp-debugsource-3.7.4-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1903</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-12-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48706" id="CVE-2023-48706" title="CVE-2023-48706" type="cve"></reference>
          </references>
          <description>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-48706)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="23.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="23.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="23.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="23.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="23.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="23.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="23.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="23.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="23.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="23.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="23.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="23.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="23.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1904</id>
          <title>An update for python-wheel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40898" id="CVE-2022-40898" title="CVE-2022-40898" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-40898)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="python-wheel-wheel" release="6.oe2203sp1" version="0.37.0">
                         <filename>python-wheel-wheel-0.37.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="python3-wheel" release="6.oe2203sp1" version="0.37.0">
                         <filename>python3-wheel-0.37.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1910</id>
          <title>An update for python-twisted is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39348" id="CVE-2022-39348" title="CVE-2022-39348" type="cve"></reference>
          </references>
          <description>Twisted is an event-based framework for internet applications. Started with version 0.9.4, when the host header does not match a configured host `twisted.web.vhost.NameVirtualHost` will return a `NoResource` resource which renders the Host header unescaped into the 404 response allowing HTML and script injection. In practice this should be very difficult to exploit as being able to modify the Host header of a normal HTTP request implies that one is already in a privileged position. This issue was fixed in version 22.10.0rc1. There are no known workarounds.(CVE-2022-39348)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-twisted" release="2.oe2203sp1" version="22.4.0">
                         <filename>python3-twisted-22.4.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-twisted-help" release="2.oe2203sp1" version="22.4.0">
                         <filename>python-twisted-help-22.4.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-twisted" release="2.oe2203sp1" version="22.4.0">
                         <filename>python3-twisted-22.4.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1913</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46218" id="CVE-2023-46218" title="CVE-2023-46218" type="cve"></reference>
          </references>
          <description>This flaw allows a malicious HTTP server to set &#34;super cookies&#34; in curl thatare then passed back to more origins than what is otherwise allowed orpossible. This allows a site to set cookies that then would get sent todifferent and unrelated sites and domains.It could do this by exploiting a mixed case flaw in curl&#39;s function thatverifies a given cookie domain against the Public Suffix List (PSL). Forexample a cookie could be set with `domain=co.UK` when the URL used a lowercase hostname `curl.co.uk`, even though `co.uk` is listed as a PSL domain.(CVE-2023-46218)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libcurl-devel" release="25.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl" release="25.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-help-7.79.1-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="25.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="25.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1914</id>
          <title>An update for jettison is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40149" id="CVE-2022-40149" title="CVE-2022-40149" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40150" id="CVE-2022-40150" title="CVE-2022-40150" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45685" id="CVE-2022-45685" title="CVE-2022-45685" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45693" id="CVE-2022-45693" title="CVE-2022-45693" type="cve"></reference>
          </references>
          <description>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-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 Out of memory. This effect may support a denial of service attack.(CVE-2022-40150)A stack overflow in Jettison before v1.5.2 allows attackers to cause a Denial of Service (DoS) via crafted JSON data.(CVE-2022-45685)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-45693)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jettison-javadoc" release="1.oe2203sp1" version="1.5.4">
                         <filename>jettison-javadoc-1.5.4-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jettison" release="1.oe2203sp1" version="1.5.4">
                         <filename>jettison-1.5.4-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1915</id>
          <title>An update for varnish is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45059" id="CVE-2022-45059" title="CVE-2022-45059" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-45059)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="varnish-devel" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-devel-7.0.1-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-7.0.1-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debugsource" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-debugsource-7.0.1-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debuginfo" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-debuginfo-7.0.1-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="varnish-help" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-help-7.0.1-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-7.0.1-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debugsource" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-debugsource-7.0.1-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-devel" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-devel-7.0.1-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debuginfo" release="9.oe2203sp1" version="7.0.1">
                         <filename>varnish-debuginfo-7.0.1-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1918</id>
          <title>An update for haproxy is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0836" id="CVE-2023-0836" title="CVE-2023-0836" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45539" id="CVE-2023-45539" title="CVE-2023-45539" type="cve"></reference>
          </references>
          <description>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-0836)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.(CVE-2023-45539)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="haproxy-debugsource" release="8.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy" release="8.oe2203sp1" version="2.6.6">
                         <filename>haproxy-2.6.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="haproxy-debuginfo" release="8.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="haproxy-help" release="8.oe2203sp1" version="2.6.6">
                         <filename>haproxy-help-2.6.6-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debugsource" release="8.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debugsource-2.6.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy" release="8.oe2203sp1" version="2.6.6">
                         <filename>haproxy-2.6.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="haproxy-debuginfo" release="8.oe2203sp1" version="2.6.6">
                         <filename>haproxy-debuginfo-2.6.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1920</id>
          <title>An update for liblouis is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26981" id="CVE-2022-26981" title="CVE-2022-26981" type="cve"></reference>
          </references>
          <description>Liblouis through 3.21.0 has a buffer overflow in compilePassOpcode in compileTranslationTable.c (called, indirectly, by tools/lou_checktable.c).(CVE-2022-26981)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="liblouis-debuginfo" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-debuginfo-3.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblouis-utils" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-utils-3.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblouis-debugsource" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-debugsource-3.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblouis" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-3.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="liblouis-devel" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-devel-3.7.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="liblouis-help" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-help-3.7.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-louis" release="6.oe2203sp1" version="3.7.0">
                         <filename>python3-louis-3.7.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis-devel" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-devel-3.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-3.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis-debuginfo" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-debuginfo-3.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis-debugsource" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-debugsource-3.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="liblouis-utils" release="6.oe2203sp1" version="3.7.0">
                         <filename>liblouis-utils-3.7.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1921</id>
          <title>An update for jackson-databind is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36518" id="CVE-2020-36518" title="CVE-2020-36518" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42003" id="CVE-2022-42003" title="CVE-2022-42003" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-42004" id="CVE-2022-42004" title="CVE-2022-42004" type="cve"></reference>
          </references>
          <description>jackson-databind before 2.13.0 allows a Java StackOverflow exception and denial of service via a large depth of nested objects.(CVE-2020-36518)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. Additional fix version in 2.13.4.1 and 2.12.17.1(CVE-2022-42003)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-2022-42004)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jackson-databind" release="10.oe2203sp1" version="2.9.8">
                         <filename>jackson-databind-2.9.8-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jackson-databind-javadoc" release="10.oe2203sp1" version="2.9.8">
                         <filename>jackson-databind-javadoc-2.9.8-10.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1922</id>
          <title>An update for python-flask is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-30861" id="CVE-2023-30861" title="CVE-2023-30861" type="cve"></reference>
          </references>
          <description>Flask is a lightweight WSGI web application framework. When all of the following conditions are met, a response containing data intended for one client may be cached and subsequently sent by the proxy to other clients. If the proxy also caches `Set-Cookie` headers, it may send one client&#39;s `session` cookie to other clients. The severity depends on the application&#39;s use of the session and the proxy&#39;s behavior regarding cookies. The risk depends on all these conditions being met.1. The application must be hosted behind a caching proxy that does not strip cookies or ignore responses with cookies.2. The application sets `session.permanent = True`3. The application does not access or modify the session at any point during a request.4. `SESSION_REFRESH_EACH_REQUEST` enabled (the default).5. The application does not set a `Cache-Control` header to indicate that a page is private or should not be cached.This happens because vulnerable versions of Flask only set the `Vary: Cookie` header when the session is accessed or modified, not when it is refreshed (re-sent to update the expiration) without being accessed or modified. This issue has been fixed in versions 2.3.2 and 2.2.5.(CVE-2023-30861)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="python3-flask" release="4.oe2203sp1" version="2.1.2">
                         <filename>python3-flask-2.1.2-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1923</id>
          <title>An update for python-pillow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45198" id="CVE-2022-45198" title="CVE-2022-45198" type="cve"></reference>
          </references>
          <description>Pillow before 9.2.0 performs Improper Handling of Highly Compressed GIF Data (Data Amplification).(CVE-2022-45198)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-pillow-devel" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-tk" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debugsource" release="5.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debuginfo" release="5.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-qt" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pillow-help" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-help-9.0.1-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debugsource" release="5.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-qt" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-devel" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-tk" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow" release="5.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debuginfo" release="5.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1924</id>
          <title>An update for hsqldb is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41853" id="CVE-2022-41853" title="CVE-2022-41853" type="cve"></reference>
          </references>
          <description>Those using java.sql.Statement or java.sql.PreparedStatement in hsqldb (HyperSQL DataBase) to process untrusted input may be vulnerable to a remote code execution attack. By default it is allowed to call any static method of any Java class in the classpath resulting in code execution. The issue can be prevented by updating to 2.7.1 or by setting the system property &#34;hsqldb.method_class_names&#34; to classes which are allowed to be called. For example, System.setProperty(&#34;hsqldb.method_class_names&#34;, &#34;abc&#34;) or Java argument -Dhsqldb.method_class_names=&#34;abc&#34; can be used. From version 2.7.1 all classes by default are not accessible except those in java.lang.Math and need to be manually enabled.(CVE-2022-41853)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="hsqldb-lib" release="5.oe2203sp1" version="2.4.0">
                         <filename>hsqldb-lib-2.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="hsqldb-javadoc" release="5.oe2203sp1" version="2.4.0">
                         <filename>hsqldb-javadoc-2.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="hsqldb-demo" release="5.oe2203sp1" version="2.4.0">
                         <filename>hsqldb-demo-2.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="hsqldb-manual" release="5.oe2203sp1" version="2.4.0">
                         <filename>hsqldb-manual-2.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="hsqldb" release="5.oe2203sp1" version="2.4.0">
                         <filename>hsqldb-2.4.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1925</id>
          <title>An update for activemq is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41678" id="CVE-2022-41678" title="CVE-2022-41678" type="cve"></reference>
          </references>
          <description>Once an user is authenticated on Jolokia, he can potentially trigger arbitrary code execution. In details, in ActiveMQ configurations, jetty allowsorg.jolokia.http.AgentServlet to handler request to /api/jolokiaorg.jolokia.http.HttpRequestHandler#handlePostRequest is able tocreate JmxRequest through JSONObject. And calls toorg.jolokia.http.HttpRequestHandler#executeRequest.Into deeper calling stacks,org.jolokia.handler.ExecHandler#doHandleRequest is able to invokethrough refection.And then, RCE is able to be achieved viajdk.management.jfr.FlightRecorderMXBeanImpl which exists on Java version above 11.1 Call newRecording.2 Call setConfiguration. And a webshell data hides in it.3 Call startRecording.4 Call copyTo method. The webshell will be written to a .jsp file.The mitigation is to restrict (by default) the actions authorized on Jolokia, or disable Jolokia.A more restrictive Jolokia configuration has been defined in default ActiveMQ distribution. We encourage users to upgrade to ActiveMQ distributions version including updated Jolokia configuration: 5.16.6, 5.17.4, 5.18.0, 6.0.0.(CVE-2022-41678)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="activemq" release="1.oe2203sp1" version="5.16.7">
                         <filename>activemq-5.16.7-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="activemq-javadoc" release="1.oe2203sp1" version="5.16.7">
                         <filename>activemq-javadoc-5.16.7-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1928</id>
          <title>An update for perl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47100" id="CVE-2023-47100" title="CVE-2023-47100" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-47100)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="4" arch="aarch64" name="perl-debugsource" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-libs" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-devel" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="aarch64" name="perl-debuginfo" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="4" arch="noarch" name="perl-help" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-help-5.34.0-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debugsource" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-debugsource-5.34.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-libs" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-libs-5.34.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-debuginfo" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-debuginfo-5.34.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl-devel" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-devel-5.34.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="4" arch="x86_64" name="perl" release="12.oe2203sp1" version="5.34.0">
                         <filename>perl-5.34.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1929</id>
          <title>An update for xstream is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-40151" id="CVE-2022-40151" title="CVE-2022-40151" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41966" id="CVE-2022-41966" title="CVE-2022-41966" type="cve"></reference>
          </references>
          <description>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-40151)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.(CVE-2022-41966)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="xstream-hibernate" release="1.oe2203sp1" version="1.4.20">
                         <filename>xstream-hibernate-1.4.20-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xstream-benchmark" release="1.oe2203sp1" version="1.4.20">
                         <filename>xstream-benchmark-1.4.20-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xstream-parent" release="1.oe2203sp1" version="1.4.20">
                         <filename>xstream-parent-1.4.20-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xstream-javadoc" release="1.oe2203sp1" version="1.4.20">
                         <filename>xstream-javadoc-1.4.20-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xstream" release="1.oe2203sp1" version="1.4.20">
                         <filename>xstream-1.4.20-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1930</id>
          <title>An update for nodejs-tough-cookie is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26136" id="CVE-2023-26136" title="CVE-2023-26136" type="cve"></reference>
          </references>
          <description>Versions of the package tough-cookie before 4.1.3 are vulnerable to Prototype Pollution due to improper handling of Cookies when using CookieJar in rejectPublicSuffixes=false mode. This issue arises from the manner in which the objects are initialized.(CVE-2023-26136)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="nodejs-tough-cookie" release="3.oe2203sp1" version="2.3.2">
                         <filename>nodejs-tough-cookie-2.3.2-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1931</id>
          <title>An update for sox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23159" id="CVE-2021-23159" title="CVE-2021-23159" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23172" id="CVE-2021-23172" title="CVE-2021-23172" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-23210" id="CVE-2021-23210" title="CVE-2021-23210" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33844" id="CVE-2021-33844" title="CVE-2021-33844" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-26590" id="CVE-2023-26590" title="CVE-2023-26590" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-32627" id="CVE-2023-32627" title="CVE-2023-32627" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34318" id="CVE-2023-34318" title="CVE-2023-34318" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-34432" id="CVE-2023-34432" title="CVE-2023-34432" type="cve"></reference>
          </references>
          <description>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-2021-23159)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-23172)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-2021-23210)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-2021-33844)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-2023-26590)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-2023-32627)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-2023-34318)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-34432)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sox-debuginfo" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-debuginfo-14.4.2.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sox" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-14.4.2.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sox-debugsource" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-debugsource-14.4.2.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sox-devel" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-devel-14.4.2.0-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sox-help" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-help-14.4.2.0-29.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sox-debugsource" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-debugsource-14.4.2.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sox-devel" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-devel-14.4.2.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sox-debuginfo" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-debuginfo-14.4.2.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sox" release="29.oe2203sp1" version="14.4.2.0">
                         <filename>sox-14.4.2.0-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1932</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49285" id="CVE-2023-49285" title="CVE-2023-49285" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49286" id="CVE-2023-49286" title="CVE-2023-49286" type="cve"></reference>
          </references>
          <description>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-49285)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.(CVE-2023-49286)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="21.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="21.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid" release="21.oe2203sp1" version="4.9">
                         <filename>squid-4.9-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="21.oe2203sp1" version="4.9">
                         <filename>squid-4.9-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="21.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="21.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1934</id>
          <title>An update for gstreamer1-plugins-good is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37327" id="CVE-2023-37327" title="CVE-2023-37327" type="cve"></reference>
          </references>
          <description>Heap-based buffer overflow in the FLAC parser when handling malformed image tags in GStreamer versions before 1.22.4 / 1.20.7. https://gstreamer.freedesktop.org/security/sa-2023-0001.html(CVE-2023-37327)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gstreamer1-plugins-good" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-1.16.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-good-debugsource" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-debugsource-1.16.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-good-gtk" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-gtk-1.16.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-good-debuginfo" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-debuginfo-1.16.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gstreamer1-plugins-good-help" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-help-1.16.2-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-good-gtk" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-gtk-1.16.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-good" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-1.16.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-good-debugsource" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-debugsource-1.16.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-good-debuginfo" release="6.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-good-debuginfo-1.16.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1935</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39326" id="CVE-2023-39326" title="CVE-2023-39326" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45285" id="CVE-2023-45285" title="CVE-2023-45285" type="cve"></reference>
          </references>
          <description>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-39326)Using go get to fetch a module with the &#34;.git&#34; suffix may unexpectedly fallback to the insecure &#34;git://&#34; protocol if the module is unavailable via the secure &#34;https://&#34; and &#34;git+ssh://&#34; protocols, even if GOINSECURE is not set for said module. This only affects users who are not using the module proxy and are fetching modules directly (i.e. GOPROXY=off).(CVE-2023-45285)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="26.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="26.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-26.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="26.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-26.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="26.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1938</id>
          <title>An update for fish is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49284" id="CVE-2023-49284" title="CVE-2023-49284" type="cve"></reference>
          </references>
          <description>fish is a smart and user-friendly command line shell for macOS, Linux, and the rest of the family. fish shell uses certain Unicode non-characters internally for marking wildcards and expansions. It will incorrectly allow these markers to be read on command substitution output, rather than transforming them into a safe internal representation. While this may cause unexpected behavior with direct input (for example, echo \UFDD2HOME has the same output as echo $HOME), this may become a minor security problem if the output is being fed from an external program into a command substitution where this output may not be expected. This design flaw was introduced in very early versions of fish, predating the version control system, and is thought to be present in every version of fish released in the last 15 years or more, although with different characters. Code execution does not appear to be possible, but denial of service (through large brace expansion) or information disclosure (such as variable expansion) is potentially possible under certain circumstances. fish shell 3.6.2 has been released to correct this issue. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-49284)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="fish" release="6.oe2203sp1" version="3.3.1">
                         <filename>fish-3.3.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fish-debugsource" release="6.oe2203sp1" version="3.3.1">
                         <filename>fish-debugsource-3.3.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fish-debuginfo" release="6.oe2203sp1" version="3.3.1">
                         <filename>fish-debuginfo-3.3.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fish-debugsource" release="6.oe2203sp1" version="3.3.1">
                         <filename>fish-debugsource-3.3.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fish-debuginfo" release="6.oe2203sp1" version="3.3.1">
                         <filename>fish-debuginfo-3.3.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fish" release="6.oe2203sp1" version="3.3.1">
                         <filename>fish-3.3.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1941</id>
          <title>An update for erlang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37026" id="CVE-2022-37026" title="CVE-2022-37026" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-37026)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="erlang-examples" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-runtime_tools" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-compiler" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-observer" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_interface" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-sasl" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-dialyzer" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eldap" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssl" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-xmerl" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssh" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-kernel" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-asn1" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-wx" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-reltool" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-megaco" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-public_key" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-mnesia" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tftp" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erts" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-parsetools" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-crypto" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-inets" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debuginfo" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-snmp" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ftp" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-jinterface" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-diameter" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-hipe" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-edoc" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugger" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-et" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-common_test" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eunit" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_docgen" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-syntax_tools" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugsource" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-os_mon" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tools" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-stdlib" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-odbc" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_docgen" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-hipe" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-stdlib" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-megaco" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-snmp" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-observer" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-dialyzer" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssh" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-common_test" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tftp" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-kernel" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-xmerl" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-reltool" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-crypto" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-examples" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-compiler" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-odbc" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-et" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-jinterface" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-asn1" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eldap" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tools" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugger" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eunit" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-inets" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssl" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-runtime_tools" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-syntax_tools" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debuginfo" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-wx" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-os_mon" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-parsetools" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_interface" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-public_key" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ftp" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-diameter" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugsource" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-edoc" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-sasl" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erts" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-mnesia" release="3.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1943</id>
          <title>An update for gstreamer1-plugins-bad-free is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37329" id="CVE-2023-37329" title="CVE-2023-37329" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44446" id="CVE-2023-44446" title="CVE-2023-44446" type="cve"></reference>
          </references>
          <description>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(CVE-2023-37329)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-44446)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gstreamer1-plugins-bad-free-debuginfo" release="9.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-debuginfo-1.16.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-bad-free-devel" release="9.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-devel-1.16.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-bad-free" release="9.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-1.16.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-bad-free-debugsource" release="9.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-debugsource-1.16.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-bad-free-devel" release="9.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-devel-1.16.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-bad-free-debuginfo" release="9.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-debuginfo-1.16.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-bad-free-debugsource" release="9.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-debugsource-1.16.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-bad-free" release="9.oe2203sp1" version="1.16.2">
                         <filename>gstreamer1-plugins-bad-free-1.16.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1944</id>
          <title>An update for hsqldb1 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41853" id="CVE-2022-41853" title="CVE-2022-41853" type="cve"></reference>
          </references>
          <description>Those using java.sql.Statement or java.sql.PreparedStatement in hsqldb (HyperSQL DataBase) to process untrusted input may be vulnerable to a remote code execution attack. By default it is allowed to call any static method of any Java class in the classpath resulting in code execution. The issue can be prevented by updating to 2.7.1 or by setting the system property &#34;hsqldb.method_class_names&#34; to classes which are allowed to be called. For example, System.setProperty(&#34;hsqldb.method_class_names&#34;, &#34;abc&#34;) or Java argument -Dhsqldb.method_class_names=&#34;abc&#34; can be used. From version 2.7.1 all classes by default are not accessible except those in java.lang.Math and need to be manually enabled.(CVE-2022-41853)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="hsqldb1-javadoc" release="3.oe2203sp1" version="1.8.1.3">
                         <filename>hsqldb1-javadoc-1.8.1.3-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="hsqldb1" release="3.oe2203sp1" version="1.8.1.3">
                         <filename>hsqldb1-1.8.1.3-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1945</id>
          <title>An update for strongswan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-41913" id="CVE-2023-41913" title="CVE-2023-41913" type="cve"></reference>
          </references>
          <description>strongSwan before 5.9.12 has a buffer overflow and possible unauthenticated remote code execution via a DH public value that exceeds the internal buffer in charon-tkm&#39;s DH proxy. The earliest affected version is 5.3.0. An attack can occur via a crafted IKE_SA_INIT message.(CVE-2023-41913)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="strongswan-libipsec" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-libipsec-5.9.7-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="strongswan-sqlite" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-sqlite-5.9.7-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="strongswan" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-5.9.7-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="strongswan-tnc-imcvs" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-tnc-imcvs-5.9.7-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="strongswan-charon-nm" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-charon-nm-5.9.7-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="strongswan-debugsource" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-debugsource-5.9.7-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="strongswan-debuginfo" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-debuginfo-5.9.7-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="strongswan-debugsource" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-debugsource-5.9.7-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="strongswan-debuginfo" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-debuginfo-5.9.7-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="strongswan-libipsec" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-libipsec-5.9.7-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="strongswan-charon-nm" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-charon-nm-5.9.7-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="strongswan-tnc-imcvs" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-tnc-imcvs-5.9.7-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="strongswan" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-5.9.7-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="strongswan-sqlite" release="5.oe2203sp1" version="5.9.7">
                         <filename>strongswan-sqlite-5.9.7-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1946</id>
          <title>An update for logback is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6378" id="CVE-2023-6378" title="CVE-2023-6378" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6481" id="CVE-2023-6481" title="CVE-2023-6481" type="cve"></reference>
          </references>
          <description>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-6378)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.(CVE-2023-6481)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="logback-help" release="3.oe2203sp1" version="1.2.8">
                         <filename>logback-help-1.2.8-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="logback-access" release="3.oe2203sp1" version="1.2.8">
                         <filename>logback-access-1.2.8-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="logback" release="3.oe2203sp1" version="1.2.8">
                         <filename>logback-1.2.8-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="logback-examples" release="3.oe2203sp1" version="1.2.8">
                         <filename>logback-examples-1.2.8-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1947</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50269" id="CVE-2023-50269" title="CVE-2023-50269" type="cve"></reference>
          </references>
          <description>Squid is a caching proxy for the Web. Due to an Uncontrolled Recursion bug in versions 2.6 through 2.7.STABLE9, versions 3.1 through 5.9, and versions 6.0.1 through 6.5, Squid may be vulnerable to a Denial of Service attack against HTTP Request parsing. This problem allows a remote client to perform Denial of Service attack by sending a large X-Forwarded-For header when the follow_x_forwarded_for feature is configured. This bug is fixed by Squid version 6.6. In addition, patches addressing this problem for the stable releases can be found in Squid&#39;s patch archives.(CVE-2023-50269)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="22.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid" release="22.oe2203sp1" version="4.9">
                         <filename>squid-4.9-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="22.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="22.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="22.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="22.oe2203sp1" version="4.9">
                         <filename>squid-4.9-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1948</id>
          <title>An update for bluez is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45866" id="CVE-2023-45866" title="CVE-2023-45866" type="cve"></reference>
          </references>
          <description>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-45866)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bluez-debuginfo" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-debuginfo-5.54-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-devel" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-devel-5.54-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-libs" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-libs-5.54-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-5.54-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-cups" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-cups-5.54-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-debugsource" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-debugsource-5.54-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="bluez-help" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-help-5.54-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-devel" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-devel-5.54-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-5.54-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-debugsource" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-debugsource-5.54-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-libs" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-libs-5.54-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-cups" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-cups-5.54-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-debuginfo" release="18.oe2203sp1" version="5.54">
                         <filename>bluez-debuginfo-5.54-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1950</id>
          <title>An update for avro is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-43045" id="CVE-2021-43045" title="CVE-2021-43045" type="cve"></reference>
          </references>
          <description>A vulnerability in the .NET SDK of Apache Avro allows an attacker to allocate excessive resources, potentially causing a denial-of-service attack. This issue affects .NET applications using Apache Avro version 1.10.2 and prior versions. Users should update to version 1.11.0 which addresses this issue.(CVE-2021-43045)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="avro" release="4.oe2203sp1" version="1.10.2">
                         <filename>avro-1.10.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avro" release="4.oe2203sp1" version="1.10.2">
                         <filename>avro-1.10.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1951</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6377" id="CVE-2023-6377" title="CVE-2023-6377" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6478" id="CVE-2023-6478" title="CVE-2023-6478" type="cve"></reference>
          </references>
          <description>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-6377)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-6478)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="24.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1957</id>
          <title>An update for libgit2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22742" id="CVE-2023-22742" title="CVE-2023-22742" type="cve"></reference>
          </references>
          <description>libgit2 is a cross-platform, linkable library implementation of Git. When using an SSH remote with the optional libssh2 backend, libgit2 does not perform certificate checking by default. Prior versions of libgit2 require the caller to set the `certificate_check` field of libgit2&#39;s `git_remote_callbacks` structure - if a certificate check callback is not set, libgit2 does not perform any certificate checking. This means that by default - without configuring a certificate check callback, clients will not perform validation on the server SSH keys and may be subject to a man-in-the-middle attack. Users are encouraged to upgrade to v1.4.5 or v1.5.1. Users unable to upgrade should ensure that all relevant certificates are manually checked.(CVE-2023-22742)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libgit2" release="2.oe2203sp1" version="1.3.2">
                         <filename>libgit2-1.3.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgit2-devel" release="2.oe2203sp1" version="1.3.2">
                         <filename>libgit2-devel-1.3.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgit2-debuginfo" release="2.oe2203sp1" version="1.3.2">
                         <filename>libgit2-debuginfo-1.3.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgit2-debugsource" release="2.oe2203sp1" version="1.3.2">
                         <filename>libgit2-debugsource-1.3.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgit2-devel" release="2.oe2203sp1" version="1.3.2">
                         <filename>libgit2-devel-1.3.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgit2" release="2.oe2203sp1" version="1.3.2">
                         <filename>libgit2-1.3.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgit2-debugsource" release="2.oe2203sp1" version="1.3.2">
                         <filename>libgit2-debugsource-1.3.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgit2-debuginfo" release="2.oe2203sp1" version="1.3.2">
                         <filename>libgit2-debuginfo-1.3.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1961</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46219" id="CVE-2023-46219" title="CVE-2023-46219" type="cve"></reference>
          </references>
          <description>When saving HSTS data to an excessively long file name, curl could end upremoving all contents, making subsequent requests using that file unaware ofthe HSTS status they should otherwise use.(CVE-2023-46219)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libcurl-devel" release="25.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl" release="25.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-help-7.79.1-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="25.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="25.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="25.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1967</id>
          <title>An update for jettison is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1436" id="CVE-2023-1436" title="CVE-2023-1436" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-1436)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jettison-javadoc" release="1.oe2203sp1" version="1.5.4">
                         <filename>jettison-javadoc-1.5.4-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jettison" release="1.oe2203sp1" version="1.5.4">
                         <filename>jettison-1.5.4-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1969</id>
          <title>An update for ncurses is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50495" id="CVE-2023-50495" title="CVE-2023-50495" type="cve"></reference>
          </references>
          <description>NCurse v6.4-20230418 was discovered to contain a segmentation fault via the component _nc_wrap_entry().(CVE-2023-50495)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ncurses-compat-libs" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-compat-libs-6.3-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-devel" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-devel-6.3-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-help" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-help-6.3-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-static" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-static-6.3-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-6.3-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-debugsource" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-debugsource-6.3-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-debuginfo" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-debuginfo-6.3-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-libs" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-libs-6.3-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ncurses-base" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-base-6.3-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-devel" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-devel-6.3-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-static" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-static-6.3-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-debuginfo" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-debuginfo-6.3-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-6.3-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-debugsource" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-debugsource-6.3-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-compat-libs" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-compat-libs-6.3-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-libs" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-libs-6.3-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-help" release="9.oe2203sp1" version="6.3">
                         <filename>ncurses-help-6.3-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1978</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2023-12-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51385" id="CVE-2023-51385" title="CVE-2023-51385" type="cve"></reference>
          </references>
          <description>The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.(CVE-2023-48795)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.(CVE-2023-51385)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openssh-debuginfo" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-server" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.25.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-help-8.8p1-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.25.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="25.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1989</id>
          <title>An update for hdf5 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2023-12-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17433" id="CVE-2018-17433" title="CVE-2018-17433" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-17436" id="CVE-2018-17436" title="CVE-2018-17436" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-10809" id="CVE-2020-10809" title="CVE-2020-10809" type="cve"></reference>
          </references>
          <description>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-17433)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-2018-17436)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.(CVE-2020-10809)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="hdf5-openmpi-devel" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-devel-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debugsource" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debugsource-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-devel" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-devel-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-openmpi-static" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-static-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-devel" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-devel-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-debuginfo" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debuginfo-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="hdf5-mpich-static" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-static-1.12.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-devel" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-devel-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-devel" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-devel-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich-static" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-static-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debugsource" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debugsource-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-mpich" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-mpich-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-devel" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-devel-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi-static" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-static-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-debuginfo" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-debuginfo-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="hdf5-openmpi" release="6.oe2203sp1" version="1.12.1">
                         <filename>hdf5-openmpi-1.12.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1990</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6546" id="CVE-2023-6546" title="CVE-2023-6546" type="cve"></reference>
          </references>
          <description>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-6546)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.58.0.137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.58.0.137.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.58.0.137.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1992</id>
          <title>An update for tar is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2023-12-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39804" id="CVE-2023-39804" title="CVE-2023-39804" type="cve"></reference>
          </references>
          <description>A flaw was found in tar. This issue occurs when extended attributes are processed in PAX archives, and could allow an attacker to cause an application crash, resulting in a denial of service.(CVE-2023-39804)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="tar-debuginfo" release="5.oe2203sp1" version="1.34">
                         <filename>tar-debuginfo-1.34-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="tar" release="5.oe2203sp1" version="1.34">
                         <filename>tar-1.34-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="tar-debugsource" release="5.oe2203sp1" version="1.34">
                         <filename>tar-debugsource-1.34-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="tar-help" release="5.oe2203sp1" version="1.34">
                         <filename>tar-help-1.34-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="tar-debuginfo" release="5.oe2203sp1" version="1.34">
                         <filename>tar-debuginfo-1.34-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="tar" release="5.oe2203sp1" version="1.34">
                         <filename>tar-1.34-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="tar-debugsource" release="5.oe2203sp1" version="1.34">
                         <filename>tar-debugsource-1.34-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-1995</id>
          <title>An update for jgit is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4759" id="CVE-2023-4759" title="CVE-2023-4759" type="cve"></reference>
          </references>
          <description>Arbitrary File Overwrite in Eclipse JGit &lt;= 6.6.0In 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/ .The JGit maintainers would like to thank RyotaK for finding and reporting this issue.(CVE-2023-4759)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jgit-javadoc" release="3.oe2203sp1" version="5.11.0">
                         <filename>jgit-javadoc-5.11.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jgit" release="3.oe2203sp1" version="5.11.0">
                         <filename>jgit-5.11.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2023-2001</id>
          <title>An update for netty is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2023-12-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41881" id="CVE-2022-41881" title="CVE-2022-41881" type="cve"></reference>
          </references>
          <description>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-2022-41881)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="netty" release="21.oe2203sp1" version="4.1.13">
                         <filename>netty-4.1.13-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="netty-help" release="21.oe2203sp1" version="4.1.13">
                         <filename>netty-help-4.1.13-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="netty" release="21.oe2203sp1" version="4.1.13">
                         <filename>netty-4.1.13-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1001</id>
          <title>An update for ignition is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24534" id="CVE-2023-24534" title="CVE-2023-24534" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24536" id="CVE-2023-24536" title="CVE-2023-24536" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24537" id="CVE-2023-24537" title="CVE-2023-24537" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24538" id="CVE-2023-24538" title="CVE-2023-24538" type="cve"></reference>
          </references>
          <description>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-24534)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-24536)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-24537)Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. &#34;var a = {{.}}&#34;), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution.(CVE-2023-24538)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ignition-debuginfo" release="2.oe2203sp1" version="2.14.0">
                         <filename>ignition-debuginfo-2.14.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition-validate" release="2.oe2203sp1" version="2.14.0">
                         <filename>ignition-validate-2.14.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition-debugsource" release="2.oe2203sp1" version="2.14.0">
                         <filename>ignition-debugsource-2.14.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition" release="2.oe2203sp1" version="2.14.0">
                         <filename>ignition-2.14.0-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-debugsource" release="2.oe2203sp1" version="2.14.0">
                         <filename>ignition-debugsource-2.14.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition" release="2.oe2203sp1" version="2.14.0">
                         <filename>ignition-2.14.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-validate" release="2.oe2203sp1" version="2.14.0">
                         <filename>ignition-validate-2.14.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-debuginfo" release="2.oe2203sp1" version="2.14.0">
                         <filename>ignition-debuginfo-2.14.0-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1007</id>
          <title>An update for rubygem-puma is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23634" id="CVE-2022-23634" title="CVE-2022-23634" type="cve"></reference>
          </references>
          <description>Puma is a Ruby/Rack web server built for parallelism. Prior to `puma` version `5.6.2`, `puma` may not always call `close` on the response body. Rails, prior to version `7.0.2.2`, depended on the response body being closed in order for its `CurrentAttributes` implementation to work correctly. The combination of these two behaviors (Puma not closing the body + Rails&#39; Executor implementation) causes information leakage. This problem is fixed in Puma versions 5.6.2 and 4.3.11. This problem is fixed in Rails versions 7.02.2, 6.1.4.6, 6.0.4.6, and 5.2.6.2. Upgrading to a patched Rails _or_ Puma version fixes the vulnerability.(CVE-2022-23634)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="rubygem-puma" release="2.oe2203sp1" version="5.5.2">
                         <filename>rubygem-puma-5.5.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-puma-debugsource" release="2.oe2203sp1" version="5.5.2">
                         <filename>rubygem-puma-debugsource-5.5.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-puma-debuginfo" release="2.oe2203sp1" version="5.5.2">
                         <filename>rubygem-puma-debuginfo-5.5.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-puma-doc" release="2.oe2203sp1" version="5.5.2">
                         <filename>rubygem-puma-doc-5.5.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma-debugsource" release="2.oe2203sp1" version="5.5.2">
                         <filename>rubygem-puma-debugsource-5.5.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma-debuginfo" release="2.oe2203sp1" version="5.5.2">
                         <filename>rubygem-puma-debuginfo-5.5.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma" release="2.oe2203sp1" version="5.5.2">
                         <filename>rubygem-puma-5.5.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1014</id>
          <title>An update for python-twisted is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46137" id="CVE-2023-46137" title="CVE-2023-46137" type="cve"></reference>
          </references>
          <description>Twisted is an event-based framework for internet applications. Prior to version 23.10.0rc1, when sending multiple HTTP requests in one TCP packet, twisted.web will process the requests asynchronously without guaranteeing the response order. If one of the endpoints is controlled by an attacker, the attacker can delay the response on purpose to manipulate the response of the second request when a victim launched two requests using HTTP pipeline. Version 23.10.0rc1 contains a patch for this issue.(CVE-2023-46137)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-twisted" release="3.oe2203sp1" version="22.4.0">
                         <filename>python3-twisted-22.4.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-twisted-help" release="3.oe2203sp1" version="22.4.0">
                         <filename>python-twisted-help-22.4.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-twisted" release="3.oe2203sp1" version="22.4.0">
                         <filename>python3-twisted-22.4.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1016</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46751" id="CVE-2023-46751" title="CVE-2023-46751" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-46751)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-9.55.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-9.55.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="6.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1017</id>
          <title>An update for tidy is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33391" id="CVE-2021-33391" title="CVE-2021-33391" type="cve"></reference>
          </references>
          <description>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.(CVE-2021-33391)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="tidy-debuginfo" release="2.oe2203sp1" version="5.7.28">
                         <filename>tidy-debuginfo-5.7.28-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtidy" release="2.oe2203sp1" version="5.7.28">
                         <filename>libtidy-5.7.28-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tidy-debugsource" release="2.oe2203sp1" version="5.7.28">
                         <filename>tidy-debugsource-5.7.28-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtidy-devel" release="2.oe2203sp1" version="5.7.28">
                         <filename>libtidy-devel-5.7.28-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tidy" release="2.oe2203sp1" version="5.7.28">
                         <filename>tidy-5.7.28-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="tidy-help" release="2.oe2203sp1" version="5.7.28">
                         <filename>tidy-help-5.7.28-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtidy" release="2.oe2203sp1" version="5.7.28">
                         <filename>libtidy-5.7.28-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tidy" release="2.oe2203sp1" version="5.7.28">
                         <filename>tidy-5.7.28-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtidy-devel" release="2.oe2203sp1" version="5.7.28">
                         <filename>libtidy-devel-5.7.28-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tidy-debugsource" release="2.oe2203sp1" version="5.7.28">
                         <filename>tidy-debugsource-5.7.28-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tidy-debuginfo" release="2.oe2203sp1" version="5.7.28">
                         <filename>tidy-debuginfo-5.7.28-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1018</id>
          <title>An update for libsass is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-26592" id="CVE-2022-26592" title="CVE-2022-26592" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43357" id="CVE-2022-43357" title="CVE-2022-43357" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-43358" id="CVE-2022-43358" title="CVE-2022-43358" type="cve"></reference>
          </references>
          <description>Stack Overflow vulnerability in libsass 3.6.5 via the CompoundSelector::has_real_parent_ref function.(CVE-2022-26592)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.(CVE-2022-43357)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-43358)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libsass-debuginfo" release="2.oe2203sp1" version="3.6.4">
                         <filename>libsass-debuginfo-3.6.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsass" release="2.oe2203sp1" version="3.6.4">
                         <filename>libsass-3.6.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsass-debugsource" release="2.oe2203sp1" version="3.6.4">
                         <filename>libsass-debugsource-3.6.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsass-devel" release="2.oe2203sp1" version="3.6.4">
                         <filename>libsass-devel-3.6.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsass-debugsource" release="2.oe2203sp1" version="3.6.4">
                         <filename>libsass-debugsource-3.6.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsass" release="2.oe2203sp1" version="3.6.4">
                         <filename>libsass-3.6.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsass-devel" release="2.oe2203sp1" version="3.6.4">
                         <filename>libsass-devel-3.6.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsass-debuginfo" release="2.oe2203sp1" version="3.6.4">
                         <filename>libsass-debuginfo-3.6.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1019</id>
          <title>An update for bluez is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50230" id="CVE-2023-50230" title="CVE-2023-50230" type="cve"></reference>
          </references>
          <description>VUL-0: CVE-2023-50230: bluez: BlueZ Phone Book Access Profile Heap-based Buffer Overflow Remote Code Execution Vulnerability(CVE-2023-50230)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bluez-debuginfo" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-debuginfo-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-libs" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-libs-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-debugsource" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-debugsource-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-cups" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-cups-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-devel" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-devel-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="bluez-help" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-help-5.54-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-devel" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-devel-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-debuginfo" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-debuginfo-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-libs" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-libs-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-cups" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-cups-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-debugsource" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-debugsource-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1020</id>
          <title>An update for systemd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7008" id="CVE-2023-7008" title="CVE-2023-7008" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-7008)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="systemd-pam" release="63.oe2203sp1" version="249">
                         <filename>systemd-pam-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-networkd" release="63.oe2203sp1" version="249">
                         <filename>systemd-networkd-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-nspawn" release="63.oe2203sp1" version="249">
                         <filename>systemd-nspawn-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-resolved" release="63.oe2203sp1" version="249">
                         <filename>systemd-resolved-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-udev" release="63.oe2203sp1" version="249">
                         <filename>systemd-udev-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-container" release="63.oe2203sp1" version="249">
                         <filename>systemd-container-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-timesyncd" release="63.oe2203sp1" version="249">
                         <filename>systemd-timesyncd-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-debugsource" release="63.oe2203sp1" version="249">
                         <filename>systemd-debugsource-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-libs" release="63.oe2203sp1" version="249">
                         <filename>systemd-libs-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-devel" release="63.oe2203sp1" version="249">
                         <filename>systemd-devel-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd" release="63.oe2203sp1" version="249">
                         <filename>systemd-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-debuginfo" release="63.oe2203sp1" version="249">
                         <filename>systemd-debuginfo-249-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="systemd-help" release="63.oe2203sp1" version="249">
                         <filename>systemd-help-249-63.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-nspawn" release="63.oe2203sp1" version="249">
                         <filename>systemd-nspawn-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-pam" release="63.oe2203sp1" version="249">
                         <filename>systemd-pam-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-container" release="63.oe2203sp1" version="249">
                         <filename>systemd-container-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-debugsource" release="63.oe2203sp1" version="249">
                         <filename>systemd-debugsource-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-debuginfo" release="63.oe2203sp1" version="249">
                         <filename>systemd-debuginfo-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd" release="63.oe2203sp1" version="249">
                         <filename>systemd-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-devel" release="63.oe2203sp1" version="249">
                         <filename>systemd-devel-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-libs" release="63.oe2203sp1" version="249">
                         <filename>systemd-libs-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-udev" release="63.oe2203sp1" version="249">
                         <filename>systemd-udev-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-resolved" release="63.oe2203sp1" version="249">
                         <filename>systemd-resolved-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-networkd" release="63.oe2203sp1" version="249">
                         <filename>systemd-networkd-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-timesyncd" release="63.oe2203sp1" version="249">
                         <filename>systemd-timesyncd-249-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1021</id>
          <title>An update for espeak-ng is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49990" id="CVE-2023-49990" title="CVE-2023-49990" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49991" id="CVE-2023-49991" title="CVE-2023-49991" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49992" id="CVE-2023-49992" title="CVE-2023-49992" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49993" id="CVE-2023-49993" title="CVE-2023-49993" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49994" id="CVE-2023-49994" title="CVE-2023-49994" type="cve"></reference>
          </references>
          <description>Espeak-ng 1.52-dev was discovered to contain a buffer-overflow via the function SetUpPhonemeTable at synthdata.c.(CVE-2023-49990)Espeak-ng 1.52-dev was discovered to contain a Stack Buffer Underflow via the function CountVowelPosition at synthdata.c.(CVE-2023-49991)Espeak-ng 1.52-dev was discovered to contain a Stack Buffer Overflow via the function RemoveEnding at dictionary.c.(CVE-2023-49992)Espeak-ng 1.52-dev was discovered to contain a Buffer Overflow via the function ReadClause at readclause.c.(CVE-2023-49993)Espeak-ng 1.52-dev was discovered to contain a Floating Point Exception via the function PeaksToHarmspect at wavegen.c.(CVE-2023-49994)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="espeak-ng" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-1.51-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="espeak-ng-debugsource" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-debugsource-1.51-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="espeak-ng-debuginfo" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-debuginfo-1.51-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="espeak-ng-devel" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-devel-1.51-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="espeak-ng-help" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-help-1.51-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="espeak-ng-debuginfo" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-debuginfo-1.51-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="espeak-ng" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-1.51-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="espeak-ng-devel" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-devel-1.51-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="espeak-ng-debugsource" release="2.oe2203sp1" version="1.51">
                         <filename>espeak-ng-debugsource-1.51-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1024</id>
          <title>An update for metadata-extractor2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24613" id="CVE-2022-24613" title="CVE-2022-24613" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24614" id="CVE-2022-24614" title="CVE-2022-24614" type="cve"></reference>
          </references>
          <description>metadata-extractor up to 2.16.0 can throw various uncaught exceptions while parsing a specially crafted JPEG file, which could result in an application crash. This could be used to mount a denial of service attack against services that use metadata-extractor library.(CVE-2022-24613)When reading a specially crafted JPEG file, metadata-extractor up to 2.16.0 can be made to allocate large amounts of memory that finally leads to an out-of-memory error even for very small inputs. This could be used to mount a denial of service attack against services that use metadata-extractor library.(CVE-2022-24614)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="metadata-extractor2-javadoc" release="1.oe2203sp1" version="2.18.0">
                         <filename>metadata-extractor2-javadoc-2.18.0-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="metadata-extractor2" release="1.oe2203sp1" version="2.18.0">
                         <filename>metadata-extractor2-2.18.0-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1027</id>
          <title>An update for libssh is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
          </references>
          <description>The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.(CVE-2023-48795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libssh-debugsource" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-debugsource-0.9.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh-devel" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-devel-0.9.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-0.9.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh-debuginfo" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-debuginfo-0.9.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libssh-help" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-help-0.9.6-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-debuginfo" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-debuginfo-0.9.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-0.9.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-devel" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-devel-0.9.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-debugsource" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-debugsource-0.9.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1029</id>
          <title>An update for bluez is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50229" id="CVE-2023-50229" title="CVE-2023-50229" type="cve"></reference>
          </references>
          <description>VUL-0: CVE-2023-50229: bluez: BlueZ Phone Book Access Profile Heap-based Buffer Overflow Remote Code Execution Vulnerability(CVE-2023-50229)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="bluez-debugsource" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-debugsource-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-devel" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-devel-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-libs" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-libs-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-cups" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-cups-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bluez-debuginfo" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-debuginfo-5.54-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="bluez-help" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-help-5.54-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-cups" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-cups-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-debugsource" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-debugsource-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-debuginfo" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-debuginfo-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-libs" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-libs-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bluez-devel" release="19.oe2203sp1" version="5.54">
                         <filename>bluez-devel-5.54-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1033</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33631" id="CVE-2021-33631" title="CVE-2021-33631" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35827" id="CVE-2023-35827" title="CVE-2023-35827" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6606" id="CVE-2023-6606" title="CVE-2023-6606" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6610" id="CVE-2023-6610" title="CVE-2023-6610" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6817" id="CVE-2023-6817" title="CVE-2023-6817" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6931" id="CVE-2023-6931" title="CVE-2023-6931" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6932" id="CVE-2023-6932" title="CVE-2023-6932" type="cve"></reference>
          </references>
          <description>openeuler-linux-kernel-5.10.149-ext4_write_inline_data-kernel_bug-365020(CVE-2021-33631)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-35827)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-6606)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-6610)A use-after-free vulnerability in the Linux kernel&#39;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-6817)A heap out-of-bounds write vulnerability in the Linux kernel&#39;s Performance Events system component can be exploited to achieve local privilege escalation.A perf_event&#39;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-6931)A use-after-free vulnerability in the Linux kernel&#39;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-6932)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.59.0.138.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-devel" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.59.0.138.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.59.0.138.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1037</id>
          <title>An update for jersey is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28168" id="CVE-2021-28168" title="CVE-2021-28168" type="cve"></reference>
          </references>
          <description>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.(CVE-2021-28168)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jersey-javadoc" release="2.oe2203sp1" version="2.29.1">
                         <filename>jersey-javadoc-2.29.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jersey-test-framework" release="2.oe2203sp1" version="2.29.1">
                         <filename>jersey-test-framework-2.29.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jersey" release="2.oe2203sp1" version="2.29.1">
                         <filename>jersey-2.29.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1041</id>
          <title>An update for libssh is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6004" id="CVE-2023-6004" title="CVE-2023-6004" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6918" id="CVE-2023-6918" title="CVE-2023-6918" type="cve"></reference>
          </references>
          <description>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-6004)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.(CVE-2023-6918)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libssh-devel" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-devel-0.9.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-0.9.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh-debuginfo" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-debuginfo-0.9.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh-debugsource" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-debugsource-0.9.6-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libssh-help" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-help-0.9.6-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-0.9.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-devel" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-devel-0.9.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-debuginfo" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-debuginfo-0.9.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh-debugsource" release="8.oe2203sp1" version="0.9.6">
                         <filename>libssh-debugsource-0.9.6-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1046</id>
          <title>An update for python-pycryptodome is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52323" id="CVE-2023-52323" title="CVE-2023-52323" type="cve"></reference>
          </references>
          <description>PyCryptodome and pycryptodomex before 3.19.1 allow side-channel leakage for OAEP decryption, exploitable for a Manger attack.(CVE-2023-52323)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-pycryptodome-debuginfo" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodome-debuginfo-3.19.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pycryptodome" release="1.oe2203sp1" version="3.19.1">
                         <filename>python3-pycryptodome-3.19.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pycryptodome-debugsource" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodome-debugsource-3.19.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pycryptodome" release="1.oe2203sp1" version="3.19.1">
                         <filename>python3-pycryptodome-3.19.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pycryptodome-debuginfo" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodome-debuginfo-3.19.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pycryptodome-debugsource" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodome-debugsource-3.19.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1048</id>
          <title>An update for proftpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
          </references>
          <description>The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.(CVE-2023-48795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="proftpd-mysql" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-mysql-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-debuginfo" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-debuginfo-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-devel" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-devel-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-debugsource" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-debugsource-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-sqlite" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-sqlite-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-utils" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-utils-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-postgresql" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-postgresql-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-ldap" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-ldap-1.3.8b-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-ldap" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-ldap-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-debuginfo" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-debuginfo-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-devel" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-devel-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-sqlite" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-sqlite-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-debugsource" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-debugsource-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-utils" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-utils-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-postgresql" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-postgresql-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-mysql" release="3.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-mysql-1.3.8b-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1051</id>
          <title>An update for netdata is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22496" id="CVE-2023-22496" title="CVE-2023-22496" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22497" id="CVE-2023-22497" title="CVE-2023-22497" type="cve"></reference>
          </references>
          <description>Netdata is an open source option for real-time infrastructure monitoring and troubleshooting. An attacker with the ability to establish a streaming connection can execute arbitrary commands on the targeted Netdata agent. When an alert is triggered, the function `health_alarm_execute` is called. This function performs different checks and then enqueues a command by calling `spawn_enq_cmd`. This command is populated with several arguments that are not sanitized. One of them is the `registry_hostname` of the node for which the alert is raised. By providing a specially crafted `registry_hostname` as part of the health data that is streamed to a Netdata (parent) agent, an attacker can execute arbitrary commands at the remote host as a side-effect of the raised alert. Note that the commands are executed as the user running the Netdata Agent. This user is usually named `netdata`. The ability to run arbitrary commands may allow an attacker to escalate privileges by escalating other vulnerabilities in the system, as that user. The problem has been fixed in: Netdata agent v1.37 (stable) and Netdata agent v1.36.0-409 (nightly). As a workaround, streaming is not enabled by default. If you have previously enabled this, it can be disabled. Limiting access to the port on the recipient Agent to trusted child connections may mitigate the impact of this vulnerability.(CVE-2023-22496)Netdata is an open source option for real-time infrastructure monitoring and troubleshooting. Each Netdata Agent has an automatically generated MACHINE GUID. It is generated when the agent first starts and it is saved to disk, so that it will persist across restarts and reboots. Anyone who has access to a Netdata Agent has access to its MACHINE_GUID. Streaming is a feature that allows a Netdata Agent to act as parent for other Netdata Agents (children), offloading children from various functions (increased data retention, ML, health monitoring, etc) that can now be handled by the parent Agent. Configuration is done via `stream.conf`. On the parent side, users configure in `stream.conf` an API key (any random UUID can do) to provide common configuration for all children using this API key and per MACHINE GUID configuration to customize the configuration for each child. The way this was implemented, allowed an attacker to use a valid MACHINE_GUID as an API key. This affects all users who expose their Netdata Agents (children) to non-trusted users and they also expose to the same users Netdata Agent parents that aggregate data from all these children. The problem has been fixed in: Netdata agent v1.37 (stable) and Netdata agent v1.36.0-409 (nightly). As a workaround, do not enable streaming by default. If you have previously enabled this, it can be disabled. Limiting access to the port on the recipient Agent to trusted child connections may mitigate the impact of this vulnerability.(CVE-2023-22497)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="netdata-freeipmi" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-freeipmi-1.39.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="netdata-debugsource" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-debugsource-1.39.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="netdata-debuginfo" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-debuginfo-1.39.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="netdata" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-1.39.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="netdata-data" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-data-1.39.1-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="netdata-conf" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-conf-1.39.1-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="netdata-debugsource" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-debugsource-1.39.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="netdata-freeipmi" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-freeipmi-1.39.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="netdata" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-1.39.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="netdata-debuginfo" release="1.oe2203sp1" version="1.39.1">
                         <filename>netdata-debuginfo-1.39.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1053</id>
          <title>An update for python-pycryptodomex is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52323" id="CVE-2023-52323" title="CVE-2023-52323" type="cve"></reference>
          </references>
          <description>PyCryptodome and pycryptodomex before 3.19.1 allow side-channel leakage for OAEP decryption, exploitable for a Manger attack.(CVE-2023-52323)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-pycryptodomex" release="1.oe2203sp1" version="3.19.1">
                         <filename>python3-pycryptodomex-3.19.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pycryptodomex-debuginfo" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodomex-debuginfo-3.19.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pycryptodomex-debugsource" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodomex-debugsource-3.19.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-pycryptodomex-help" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodomex-help-3.19.1-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pycryptodomex-debuginfo" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodomex-debuginfo-3.19.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pycryptodomex-debugsource" release="1.oe2203sp1" version="3.19.1">
                         <filename>python-pycryptodomex-debugsource-3.19.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pycryptodomex" release="1.oe2203sp1" version="3.19.1">
                         <filename>python3-pycryptodomex-3.19.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1058</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7104" id="CVE-2023-7104" title="CVE-2023-7104" type="cve"></reference>
          </references>
          <description>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-2023-7104)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox-debugsource" release="4.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="4.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox" release="4.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="4.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="4.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="4.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1063</id>
          <title>An update for sqlite is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7104" id="CVE-2023-7104" title="CVE-2023-7104" type="cve"></reference>
          </references>
          <description>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-2023-7104)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sqlite" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-3.37.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite-devel" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-devel-3.37.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite-debugsource" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debugsource-3.37.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sqlite-debuginfo" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debuginfo-3.37.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sqlite-help" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-help-3.37.2-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-debuginfo" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debuginfo-3.37.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-devel" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-devel-3.37.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-3.37.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sqlite-debugsource" release="7.oe2203sp1" version="3.37.2">
                         <filename>sqlite-debugsource-3.37.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1064</id>
          <title>An update for yasm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31975" id="CVE-2023-31975" title="CVE-2023-31975" type="cve"></reference>
          </references>
          <description>yasm v1.3.0 was discovered to contain a memory leak via the function yasm_intnum_copy at /libyasm/intnum.c.(CVE-2023-31975)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="yasm-debuginfo" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-debuginfo-1.3.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-devel" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-devel-1.3.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm-debugsource" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-debugsource-1.3.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="yasm" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-1.3.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="yasm-help" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-help-1.3.0-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-debugsource" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-debugsource-1.3.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-1.3.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-debuginfo" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-debuginfo-1.3.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="yasm-devel" release="12.oe2203sp1" version="1.3.0">
                         <filename>yasm-devel-1.3.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1070</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0208" id="CVE-2024-0208" title="CVE-2024-0208" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0209" id="CVE-2024-0209" title="CVE-2024-0209" type="cve"></reference>
          </references>
          <description>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-0208)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(CVE-2024-0209)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="6.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1071</id>
          <title>An update for sudo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42465" id="CVE-2023-42465" title="CVE-2023-42465" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-42465)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sudo-debuginfo" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debuginfo-1.9.8p2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-debugsource" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debugsource-1.9.8p2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo-devel" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-devel-1.9.8p2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sudo" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-1.9.8p2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sudo-help" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-help-1.9.8p2-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-1.9.8p2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-devel" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-devel-1.9.8p2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-debuginfo" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debuginfo-1.9.8p2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sudo-debugsource" release="15.oe2203sp1" version="1.9.8p2">
                         <filename>sudo-debugsource-1.9.8p2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1072</id>
          <title>An update for testng is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4065" id="CVE-2022-4065" title="CVE-2022-4065" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-4065)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="testng" release="7.oe2203sp1" version="6.14.3">
                         <filename>testng-6.14.3-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="testng-javadoc" release="7.oe2203sp1" version="6.14.3">
                         <filename>testng-javadoc-6.14.3-7.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1074</id>
          <title>An update for containernetworking-plugins is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-01-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24534" id="CVE-2023-24534" title="CVE-2023-24534" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24536" id="CVE-2023-24536" title="CVE-2023-24536" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24537" id="CVE-2023-24537" title="CVE-2023-24537" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24538" id="CVE-2023-24538" title="CVE-2023-24538" type="cve"></reference>
          </references>
          <description>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-24534)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-24536)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-24537)Templates do not properly consider backticks (`) as Javascript string delimiters, and do not escape them as expected. Backticks are used, since ES6, for JS template literals. If a template contains a Go template action within a Javascript template literal, the contents of the action can be used to terminate the literal, injecting arbitrary Javascript code into the Go template. As ES6 template literals are rather complex, and themselves can do string interpolation, the decision was made to simply disallow Go template actions from being used inside of them (e.g. &#34;var a = {{.}}&#34;), since there is no obviously safe way to allow this behavior. This takes the same approach as github.com/google/safehtml. With fix, Template.Parse returns an Error when it encounters templates like this, with an ErrorCode of value 12. This ErrorCode is currently unexported, but will be exported in the release of Go 1.21. Users who rely on the previous behavior can re-enable it using the GODEBUG flag jstmpllitinterp=1, with the caveat that backticks will now be escaped. This should be used with caution.(CVE-2023-24538)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="containernetworking-plugins-unit-test-devel" release="4.oe2203sp1" version="1.1.1">
                         <filename>containernetworking-plugins-unit-test-devel-1.1.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="containernetworking-plugins" release="4.oe2203sp1" version="1.1.1">
                         <filename>containernetworking-plugins-1.1.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="containernetworking-plugins-devel" release="4.oe2203sp1" version="1.1.1">
                         <filename>containernetworking-plugins-devel-1.1.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="containernetworking-plugins-unit-test-devel" release="4.oe2203sp1" version="1.1.1">
                         <filename>containernetworking-plugins-unit-test-devel-1.1.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="containernetworking-plugins" release="4.oe2203sp1" version="1.1.1">
                         <filename>containernetworking-plugins-1.1.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1075</id>
          <title>An update for proftpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51713" id="CVE-2023-51713" title="CVE-2023-51713" type="cve"></reference>
          </references>
          <description>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-51713)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="proftpd-debuginfo" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-debuginfo-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-sqlite" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-sqlite-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-debugsource" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-debugsource-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-mysql" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-mysql-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-ldap" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-ldap-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-devel" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-devel-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-utils" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-utils-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd-postgresql" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-postgresql-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="proftpd" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-1.3.8b-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-debugsource" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-debugsource-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-mysql" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-mysql-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-sqlite" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-sqlite-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-postgresql" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-postgresql-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-ldap" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-ldap-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-debuginfo" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-debuginfo-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-devel" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-devel-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="proftpd-utils" release="4.oe2203sp1" version="1.3.8b">
                         <filename>proftpd-utils-1.3.8b-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1076</id>
          <title>An update for mongo-c-driver is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0437" id="CVE-2023-0437" title="CVE-2023-0437" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-0437)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mongo-c-driver" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-1.13.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libbson-devel" release="7.oe2203sp1" version="1.13.1">
                         <filename>libbson-devel-1.13.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libbson" release="7.oe2203sp1" version="1.13.1">
                         <filename>libbson-1.13.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debuginfo" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-debuginfo-1.13.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-devel" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-devel-1.13.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-help" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-help-1.13.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debugsource" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-debugsource-1.13.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debugsource" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-debugsource-1.13.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-help" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-help-1.13.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson" release="7.oe2203sp1" version="1.13.1">
                         <filename>libbson-1.13.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-1.13.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson-devel" release="7.oe2203sp1" version="1.13.1">
                         <filename>libbson-devel-1.13.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-devel" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-devel-1.13.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debuginfo" release="7.oe2203sp1" version="1.13.1">
                         <filename>mongo-c-driver-debuginfo-1.13.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1077</id>
          <title>An update for rear is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23301" id="CVE-2024-23301" title="CVE-2024-23301" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-23301)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rear-help" release="5.oe2203sp1" version="2.4">
                         <filename>rear-help-2.4-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rear" release="5.oe2203sp1" version="2.4">
                         <filename>rear-2.4-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1078</id>
          <title>An update for libexif is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-01-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-0452" id="CVE-2020-0452" title="CVE-2020-0452" type="cve"></reference>
          </references>
          <description>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(CVE-2020-0452)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libexif-debugsource" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-debugsource-0.6.22-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libexif" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-0.6.22-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libexif-devel" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-devel-0.6.22-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libexif-debuginfo" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-debuginfo-0.6.22-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libexif-help" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-help-0.6.22-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libexif-debuginfo" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-debuginfo-0.6.22-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libexif" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-0.6.22-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libexif-debugsource" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-debugsource-0.6.22-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libexif-devel" release="5.oe2203sp1" version="0.6.22">
                         <filename>libexif-devel-0.6.22-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1079</id>
          <title>An update for apache-sshd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-35887" id="CVE-2023-35887" title="CVE-2023-35887" type="cve"></reference>
          </references>
          <description>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 &#34;exists/does not exist&#34; information about items outside the rooted tree via paths including parent navigation (&#34;..&#34;) beyond the root, or involving symlinks.This issue affects Apache MINA: from 1.0 before 2.10. Users are recommended to upgrade to 2.10(CVE-2023-35887)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="apache-sshd" release="2.oe2203sp1" version="2.9.2">
                         <filename>apache-sshd-2.9.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="apache-sshd-javadoc" release="2.oe2203sp1" version="2.9.2">
                         <filename>apache-sshd-javadoc-2.9.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1082</id>
          <title>An update for python-paramiko is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
          </references>
          <description>The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.(CVE-2023-48795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-paramiko" release="3.oe2203sp1" version="2.11.0">
                         <filename>python3-paramiko-2.11.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-paramiko-help" release="3.oe2203sp1" version="2.11.0">
                         <filename>python-paramiko-help-2.11.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1086</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51779" id="CVE-2023-51779" title="CVE-2023-51779" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51780" id="CVE-2023-51780" title="CVE-2023-51780" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51781" id="CVE-2023-51781" title="CVE-2023-51781" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51782" id="CVE-2023-51782" title="CVE-2023-51782" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6121" id="CVE-2023-6121" title="CVE-2023-6121" type="cve"></reference>
          </references>
          <description>A flaw was found in the Bluetooth subsystem of the Linux kernel. A race condition between the bt_sock_recvmsg() and bt_sock_ioctl() functions could lead to a use-after-free on a socket buffer (&#34;skb&#34;). This flaw allows a local user to cause a denial of service condition or potential code execution.(CVE-2023-51779)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-2023-51780)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-51781)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-51782)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-6121)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-debugsource" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bpftool" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.60.0.139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>bpftool-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bpftool-debuginfo" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>bpftool-debuginfo-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.60.0.139.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.60.0.139.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1094</id>
          <title>An update for gnutls is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0553" id="CVE-2024-0553" title="CVE-2024-0553" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0567" id="CVE-2024-0567" title="CVE-2024-0567" type="cve"></reference>
          </references>
          <description>A vulnerability was found in GnuTLS. The response times to malformed ciphertexts in RSA-PSK ClientKeyExchange differ from 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-0553)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.(CVE-2024-0567)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnutls" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debugsource" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-devel" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-utils" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debuginfo" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnutls-help" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-help-3.7.2-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-utils" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debuginfo" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-devel" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debugsource" release="11.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1096</id>
          <title>An update for pam is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22365" id="CVE-2024-22365" title="CVE-2024-22365" type="cve"></reference>
          </references>
          <description>A vulnerability was found in Linux PAM. An unprivileged user that is not yet in a corresponding mount namespace with ~/tmp mounted as a polyinstantiated dir can place a FIFO there, and a subsequent attempt to login as this user with `pam_namespace` configured will cause the `openat()` in `protect_dir()` to block the attempt, causing a local denial of service.(CVE-2024-22365)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pam-debugsource" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-debugsource-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam-debuginfo" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-debuginfo-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam-devel" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-devel-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="pam-help" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-help-1.5.2-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-devel" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-devel-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-debuginfo" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-debuginfo-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam-debugsource" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-debugsource-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam" release="7.oe2203sp1" version="1.5.2">
                         <filename>pam-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1097</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6040" id="CVE-2023-6040" title="CVE-2023-6040" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0565" id="CVE-2024-0565" title="CVE-2024-0565" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0607" id="CVE-2024-0607" title="CVE-2024-0607" type="cve"></reference>
          </references>
          <description>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-2023-6040)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-0565)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-2024-0607)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-devel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-debugsource" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1098</id>
          <title>An update for python-pillow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50447" id="CVE-2023-50447" title="CVE-2023-50447" type="cve"></reference>
          </references>
          <description>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).(CVE-2023-50447)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-pillow-qt" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debuginfo" release="6.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-tk" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debugsource" release="6.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-devel" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pillow-help" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-help-9.0.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debuginfo" release="6.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-qt" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-tk" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-devel" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow" release="6.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debugsource" release="6.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1100</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-24998" id="CVE-2023-24998" title="CVE-2023-24998" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28709" id="CVE-2023-28709" title="CVE-2023-28709" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42795" id="CVE-2023-42795" title="CVE-2023-42795" type="cve"></reference>
          </references>
          <description>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-24998)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-28709)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-2023-42795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="33.oe2203sp1" version="9.0.10">
                         <filename>tomcat-jsvc-9.0.10-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat" release="33.oe2203sp1" version="9.0.10">
                         <filename>tomcat-9.0.10-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="33.oe2203sp1" version="9.0.10">
                         <filename>tomcat-help-9.0.10-33.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1101</id>
          <title>An update for apache-sshd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
          </references>
          <description>The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.(CVE-2023-48795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="apache-sshd-javadoc" release="3.oe2203sp1" version="2.9.2">
                         <filename>apache-sshd-javadoc-2.9.2-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="apache-sshd" release="3.oe2203sp1" version="2.9.2">
                         <filename>apache-sshd-2.9.2-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1102</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6816" id="CVE-2023-6816" title="CVE-2023-6816" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0229" id="CVE-2024-0229" title="CVE-2024-0229" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0408" id="CVE-2024-0408" title="CVE-2024-0408" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0409" id="CVE-2024-0409" title="CVE-2024-0409" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21885" id="CVE-2024-21885" title="CVE-2024-21885" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21886" id="CVE-2024-21886" title="CVE-2024-21886" type="cve"></reference>
          </references>
          <description>A flaw was found in X.Org server. Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for each logical button currently down. Buttons can be arbitrarily mapped to any value up to 255, but the X.Org Server was only allocating space for the device&#39;s particular number of buttons, leading to a heap overflow if a bigger value was used.(CVE-2023-6816)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-2024-0229)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-0408)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-2024-0409)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-21885)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-21886)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="25.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1103</id>
          <title>An update for mysql-connector-java is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-2471" id="CVE-2021-2471" title="CVE-2021-2471" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-21363" id="CVE-2022-21363" title="CVE-2022-21363" type="cve"></reference>
          </references>
          <description>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-2021-2471)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).(CVE-2022-21363)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="mysql-connector-java" release="1.oe2203sp1" version="8.0.30">
                         <filename>mysql-connector-java-8.0.30-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1105</id>
          <title>An update for grafana is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32148" id="CVE-2022-32148" title="CVE-2022-32148" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
          </references>
          <description>Improper exposure of client IP addresses in net/http before Go 1.17.12 and Go 1.18.4 can be triggered by calling httputil.ReverseProxy.ServeHTTP with a Request.Header map containing a nil value for the X-Forwarded-For header, which causes ReverseProxy to set the client IP as the value of the X-Forwarded-For header.(CVE-2022-32148)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.(CVE-2023-39325)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="grafana" release="6.oe2203sp1" version="7.5.15">
                         <filename>grafana-7.5.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grafana-debuginfo" release="6.oe2203sp1" version="7.5.15">
                         <filename>grafana-debuginfo-7.5.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana-debuginfo" release="6.oe2203sp1" version="7.5.15">
                         <filename>grafana-debuginfo-7.5.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana" release="6.oe2203sp1" version="7.5.15">
                         <filename>grafana-7.5.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1106</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-01-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48619" id="CVE-2022-48619" title="CVE-2022-48619" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0340" id="CVE-2024-0340" title="CVE-2024-0340" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0641" id="CVE-2024-0641" title="CVE-2024-0641" type="cve"></reference>
          </references>
          <description>An issue was discovered in drivers/input/input.c in the Linux kernel before 5.17.10. An attacker can cause a denial of service (panic) because input_set_capability mishandles the situation in which an event code falls outside of a bitmap.(CVE-2022-48619)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-0340)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-0641)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-devel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.61.0.141.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-source" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-debugsource" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.61.0.141.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.61.0.141.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1107</id>
          <title>An update for tomcat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-01-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21733" id="CVE-2024-21733" title="CVE-2024-21733" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-21733)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="tomcat-help" release="33.oe2203sp1" version="9.0.10">
                         <filename>tomcat-help-9.0.10-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat" release="33.oe2203sp1" version="9.0.10">
                         <filename>tomcat-9.0.10-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="tomcat-jsvc" release="33.oe2203sp1" version="9.0.10">
                         <filename>tomcat-jsvc-9.0.10-33.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1108</id>
          <title>An update for freerdp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22211" id="CVE-2024-22211" title="CVE-2024-22211" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-22211)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="freerdp-debugsource" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-debugsource-2.11.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libwinpr-devel" release="2.oe2203sp1" version="2.11.1">
                         <filename>libwinpr-devel-2.11.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-devel" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-devel-2.11.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libwinpr" release="2.oe2203sp1" version="2.11.1">
                         <filename>libwinpr-2.11.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-2.11.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-help" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-help-2.11.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-debuginfo" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-debuginfo-2.11.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-debuginfo" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-debuginfo-2.11.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-devel" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-devel-2.11.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libwinpr" release="2.oe2203sp1" version="2.11.1">
                         <filename>libwinpr-2.11.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-help" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-help-2.11.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-2.11.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libwinpr-devel" release="2.oe2203sp1" version="2.11.1">
                         <filename>libwinpr-devel-2.11.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-debugsource" release="2.oe2203sp1" version="2.11.1">
                         <filename>freerdp-debugsource-2.11.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1112</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46343" id="CVE-2023-46343" title="CVE-2023-46343" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51042" id="CVE-2023-51042" title="CVE-2023-51042" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22705" id="CVE-2024-22705" title="CVE-2024-22705" type="cve"></reference>
          </references>
          <description>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-46343)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-51042)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-2024-22705)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="kernel-source" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.62.0.142.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.62.0.142.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.62.0.142.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1118</id>
          <title>An update for shim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40547" id="CVE-2023-40547" title="CVE-2023-40547" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40548" id="CVE-2023-40548" title="CVE-2023-40548" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40549" id="CVE-2023-40549" title="CVE-2023-40549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40550" id="CVE-2023-40550" title="CVE-2023-40550" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40551" id="CVE-2023-40551" title="CVE-2023-40551" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-40547)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-40548)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-40549)An out-of-bounds read flaw was found in Shim when it tried to validate the SBAT information. This issue may expose sensitive data during the system&#39;s boot phase.(CVE-2023-40550)A flaw was found in the MZ binary format in Shim. An out-of-bounds read may occur, leading to a crash or possible exposure of sensitive data during the system&#39;s boot phase.(CVE-2023-40551)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="shim" release="16.oe2203sp1" version="15.6">
                         <filename>shim-15.6-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debuginfo" release="16.oe2203sp1" version="15.6">
                         <filename>shim-debuginfo-15.6-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debugsource" release="16.oe2203sp1" version="15.6">
                         <filename>shim-debugsource-15.6-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="shim" release="16.oe2203sp1" version="15.6">
                         <filename>shim-15.6-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1121</id>
          <title>An update for jruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28756" id="CVE-2023-28756" title="CVE-2023-28756" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-28756)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jruby-javadoc" release="4.oe2203sp1" version="1.7.22">
                         <filename>jruby-javadoc-1.7.22-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jruby-devel" release="4.oe2203sp1" version="1.7.22">
                         <filename>jruby-devel-1.7.22-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="jruby" release="4.oe2203sp1" version="1.7.22">
                         <filename>jruby-1.7.22-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1122</id>
          <title>An update for erlang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
          </references>
          <description>The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.(CVE-2023-48795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="erlang-debugger" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ftp" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-mnesia" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssl" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-kernel" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-reltool" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-crypto" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-os_mon" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eunit" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debuginfo" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-ssh" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-compiler" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-odbc" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-debugsource" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-runtime_tools" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-common_test" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-stdlib" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-inets" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-snmp" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-dialyzer" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-asn1" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tools" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-megaco" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-et" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-public_key" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-examples" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-parsetools" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-syntax_tools" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_docgen" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-jinterface" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-xmerl" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erl_interface" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-diameter" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-erts" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-eldap" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-hipe" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-observer" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-sasl" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-edoc" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-wx" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="erlang-tftp" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-crypto" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-crypto-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-sasl" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-sasl-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-asn1" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-asn1-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-jinterface" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-jinterface-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-reltool" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-reltool-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-observer" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-observer-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-compiler" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-compiler-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ftp" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ftp-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-kernel" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-kernel-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-odbc" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-odbc-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-syntax_tools" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-syntax_tools-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-edoc" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-edoc-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-dialyzer" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-dialyzer-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-inets" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-inets-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-runtime_tools" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-runtime_tools-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-xmerl" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-xmerl-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-os_mon" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-os_mon-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tftp" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-tftp-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssh" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ssh-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-diameter" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-diameter-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-mnesia" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-mnesia-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erts" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erts-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-tools" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-tools-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-wx" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-wx-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_interface" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erl_interface-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-erl_docgen" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-erl_docgen-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugsource" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debugsource-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-ssl" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-ssl-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debuginfo" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debuginfo-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-megaco" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-megaco-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-hipe" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-hipe-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eunit" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-eunit-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-snmp" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-snmp-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-public_key" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-public_key-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-examples" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-examples-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-et" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-et-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-eldap" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-eldap-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-stdlib" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-stdlib-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-debugger" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-debugger-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-common_test" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-common_test-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="erlang-parsetools" release="4.oe2203sp1" version="23.3.4.9">
                         <filename>erlang-parsetools-23.3.4.9-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1124</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23638" id="CVE-2024-23638" title="CVE-2024-23638" type="cve"></reference>
          </references>
          <description>Squid is a caching proxy for the Web. Due to an expired pointer reference bug, Squid prior to version 6.6 is vulnerable to a Denial of Service attack against Cache Manager error responses. This problem allows a trusted client to perform Denial of Service when generating error pages for Client Manager reports. Squid older than 5.0.5 have not been tested and should be assumed to be vulnerable. All Squid-5.x up to and including 5.9 are vulnerable. All Squid-6.x up to and including 6.5 are vulnerable. This bug is fixed by Squid version 6.6. In addition, patches addressing this problem for the stable releases can be found in Squid&#39;s patch archives. As a workaround, prevent access to Cache Manager using Squid&#39;s main access control: `http_access deny manager`.(CVE-2024-23638)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="23.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid" release="23.oe2203sp1" version="4.9">
                         <filename>squid-4.9-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="23.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="23.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="23.oe2203sp1" version="4.9">
                         <filename>squid-4.9-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="23.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1125</id>
          <title>An update for ncurses is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45918" id="CVE-2023-45918" title="CVE-2023-45918" type="cve"></reference>
          </references>
          <description>A vulnerability was found in GNU ncurses 6.4-20230610. It has been rated as problematic. This issue affects the function tgetstr. There is no information about possible countermeasures known. It may be suggested to replace the affected object with an alternative product.(CVE-2023-45918)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ncurses-static" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-static-6.3-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-debugsource" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-debugsource-6.3-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-6.3-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-devel" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-devel-6.3-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-help" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-help-6.3-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-debuginfo" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-debuginfo-6.3-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-libs" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-libs-6.3-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ncurses-compat-libs" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-compat-libs-6.3-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ncurses-base" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-base-6.3-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-debuginfo" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-debuginfo-6.3-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-6.3-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-help" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-help-6.3-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-static" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-static-6.3-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-devel" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-devel-6.3-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-compat-libs" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-compat-libs-6.3-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-debugsource" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-debugsource-6.3-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ncurses-libs" release="10.oe2203sp1" version="6.3">
                         <filename>ncurses-libs-6.3-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1126</id>
          <title>An update for containerd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-39325)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="containerd" release="316.oe2203sp1" version="1.2.0">
                         <filename>containerd-1.2.0-316.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="containerd" release="316.oe2203sp1" version="1.2.0">
                         <filename>containerd-1.2.0-316.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1127</id>
          <title>An update for openjdk-1.8.0 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20919" id="CVE-2024-20919" title="CVE-2024-20919" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20921" id="CVE-2024-20921" title="CVE-2024-20921" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20922" id="CVE-2024-20922" title="CVE-2024-20922" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20923" id="CVE-2024-20923" title="CVE-2024-20923" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20925" id="CVE-2024-20925" title="CVE-2024-20925" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20926" id="CVE-2024-20926" title="CVE-2024-20926" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20945" id="CVE-2024-20945" title="CVE-2024-20945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20952" id="CVE-2024-20952" title="CVE-2024-20952" type="cve"></reference>
          </references>
          <description></description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-src-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.402.b06-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc-zip" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.402.b06-0.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-javadoc-1.8.0.402.b06-0.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-src-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk" release="0.oe2203sp1" version="1.8.0.402.b06">
                         <filename>java-1.8.0-openjdk-1.8.0.402.b06-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1128</id>
          <title>An update for python-jinja2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22195" id="CVE-2024-22195" title="CVE-2024-22195" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-22195)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-jinja2" release="3.oe2203sp1" version="3.0.3">
                         <filename>python3-jinja2-3.0.3-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-jinja2-help" release="3.oe2203sp1" version="3.0.3">
                         <filename>python-jinja2-help-3.0.3-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1137</id>
          <title>An update for nodejs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
          </references>
          <description>A security vulnerability has been identified in all supported versionsof OpenSSL related to the verification of X.509 certificate chainsthat include policy constraints.  Attackers may be able to exploit thisvulnerability by creating a malicious certificate chain that triggersexponential 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 passingthe `-policy&#39; argument to the command line utilities or by calling the`X509_VERIFY_PARAM_set1_policies()&#39; function.(CVE-2023-0464)Applications that use a non-default option when verifying certificates may bevulnerable to an attack from a malicious CA to circumvent certain checks.Invalid certificate policies in leaf certificates are silently ignored byOpenSSL and other certificate policy checks are skipped for that certificate.A malicious CA could use this to deliberately assert invalid certificate policiesin order to circumvent policy checking on the certificate altogether.Policy processing is disabled by default but can be enabled by passingthe `-policy&#39; argument to the command line utilities or by calling the`X509_VERIFY_PARAM_set1_policies()&#39; function.(CVE-2023-0465)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="v8-devel" release="1.12.22.11.9.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debuginfo" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-devel" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debugsource" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-libs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-full-i18n" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="npm" release="1.12.22.11.9.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nodejs-docs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-docs-12.22.11-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-full-i18n" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="npm" release="1.12.22.11.9.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debugsource" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="v8-devel" release="1.12.22.11.9.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debuginfo" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-libs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-devel" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1139</id>
          <title>An update for containerd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
          </references>
          <description>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-41723)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="containerd" release="317.oe2203sp1" version="1.2.0">
                         <filename>containerd-1.2.0-317.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="containerd" release="317.oe2203sp1" version="1.2.0">
                         <filename>containerd-1.2.0-317.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1143</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51043" id="CVE-2023-51043" title="CVE-2023-51043" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6531" id="CVE-2023-6531" title="CVE-2023-6531" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6915" id="CVE-2023-6915" title="CVE-2023-6915" type="cve"></reference>
          </references>
          <description>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-51043)A use-after-free flaw was found in the Linux Kernel due to a race problem in the unix garbage collector&#39;s deletion of SKB races with unix_stream_read_generic() on the socket that the SKB is queued on.(CVE-2023-6531)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-6915)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.63.0.143.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.63.0.143.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.63.0.143.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1146</id>
          <title>An update for rubygem-actionpack is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22792" id="CVE-2023-22792" title="CVE-2023-22792" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22795" id="CVE-2023-22795" title="CVE-2023-22795" type="cve"></reference>
          </references>
          <description>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-22792)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.(CVE-2023-22795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack-doc" release="4.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-actionpack-doc-6.1.4.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack" release="4.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-actionpack-6.1.4.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1147</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
          </references>
          <description>Issue summary: Processing a maliciously formatted PKCS12 file may lead OpenSSLto crash leading to a potential Denial of Service attackImpact summary: Applications loading files in the PKCS12 format from untrustedsources might terminate abruptly.A file in PKCS12 format can contain certificates and keys and may come from anuntrusted source. The PKCS12 specification allows certain fields to be NULL, butOpenSSL does not correctly check for this case. This can lead to a NULL pointerdereference that results in OpenSSL crashing. If an application processes PKCS12files from an untrusted source using the OpenSSL APIs then that application willbe 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 thisfunction 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.(CVE-2024-0727)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="32.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1148</id>
          <title>An update for three-eight-nine-ds-base is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1062" id="CVE-2024-1062" title="CVE-2024-1062" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-1062)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="389-ds-base" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-snmp" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-legacy-tools" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debuginfo" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-devel" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-help" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debugsource" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-lib389" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>python3-lib389-1.4.3.36-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-389-ds" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>cockpit-389-ds-1.4.3.36-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-legacy-tools" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-snmp" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-devel" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debugsource" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-help" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debuginfo" release="5.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1152</id>
          <title>An update for openjdk-11 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20919" id="CVE-2024-20919" title="CVE-2024-20919" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20921" id="CVE-2024-20921" title="CVE-2024-20921" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20926" id="CVE-2024-20926" title="CVE-2024-20926" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20945" id="CVE-2024-20945" title="CVE-2024-20945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20952" id="CVE-2024-20952" title="CVE-2024-20952" type="cve"></reference>
          </references>
          <description>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-20918)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.(CVE-2024-20919)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.(CVE-2024-20921)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-20926)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 applies to Java deployments, typically in clients running sandboxed Java Web Start applications or sandboxed 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-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 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-20952)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debugsource" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-debugsource-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-src-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-src-slowdebug-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-headless-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-demo-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-devel-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-jmods-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-javadoc-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debuginfo" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-debuginfo-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-slowdebug-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc-zip" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-javadoc-zip-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.22.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-jmods-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debuginfo" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-debuginfo-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-headless-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc-zip" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-javadoc-zip-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-devel-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-src-slowdebug-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-slowdebug-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel-slowdebug" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-javadoc-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-src-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debugsource" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-debugsource-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo" release="0.oe2203sp1" version="11.0.22.7">
                         <filename>java-11-openjdk-demo-11.0.22.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1158</id>
          <title>An update for zbar is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-02-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40889" id="CVE-2023-40889" title="CVE-2023-40889" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40890" id="CVE-2023-40890" title="CVE-2023-40890" type="cve"></reference>
          </references>
          <description>A heap-based buffer overflow exists in the qr_reader_match_centers function of ZBar 0.23.90. Specially crafted QR codes may lead to information disclosure and/or arbitrary code execution. To trigger this vulnerability, an attacker can digitally input the malicious QR code, or prepare it to be physically scanned by the vulnerable scanner.(CVE-2023-40889)A stack-based buffer overflow vulnerability exists in the lookup_sequence function of ZBar 0.23.90. Specially crafted QR codes may lead to information disclosure and/or arbitrary code execution. To trigger this vulnerability, an attacker can digitally input the malicious QR code, or prepare it to be physically scanned by the vulnerable scanner.(CVE-2023-40890)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="zbar-gtk-devel" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-gtk-devel-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zbar" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zbar-devel" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-devel-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zbar-qt-devel" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-qt-devel-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zbar-qt" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-qt-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zbar-debuginfo" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-debuginfo-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zbar-libs" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-libs-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-zbar" release="1.oe2203sp1" version="0.23.93">
                         <filename>python3-zbar-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zbar-gtk" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-gtk-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zbar-debugsource" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-debugsource-0.23.93-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar-debugsource" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-debugsource-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar-gtk-devel" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-gtk-devel-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar-gtk" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-gtk-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-zbar" release="1.oe2203sp1" version="0.23.93">
                         <filename>python3-zbar-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar-libs" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-libs-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar-qt" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-qt-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar-qt-devel" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-qt-devel-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar-devel" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-devel-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zbar-debuginfo" release="1.oe2203sp1" version="0.23.93">
                         <filename>zbar-debuginfo-0.23.93-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1161</id>
          <title>An update for qt5-qtbase is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51714" id="CVE-2023-51714" title="CVE-2023-51714" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-51714)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtbase-mysql" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-odbc" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-postgresql" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-gui" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debuginfo" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-static" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debugsource" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-examples" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-devel" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-private-devel" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qt5-qtbase-common" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-common-5.15.2-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-postgresql" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-mysql" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-examples" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debuginfo" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-devel" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-gui" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-static" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-private-devel" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debugsource" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-odbc" release="14.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1162</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25617" id="CVE-2024-25617" title="CVE-2024-25617" type="cve"></reference>
          </references>
          <description>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(CVE-2024-25617)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="squid" release="24.oe2203sp1" version="4.9">
                         <filename>squid-4.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="24.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="24.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="24.oe2203sp1" version="4.9">
                         <filename>squid-4.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="24.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="24.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1172</id>
          <title>An update for nodejs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
          </references>
          <description>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-2023-44487)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="v8-devel" release="1.12.22.11.9.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-full-i18n" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="npm" release="1.12.22.11.9.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-libs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debuginfo" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debugsource" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-devel" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nodejs-docs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-docs-12.22.11-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="v8-devel" release="1.12.22.11.9.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-libs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-devel" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debugsource" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="npm" release="1.12.22.11.9.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-full-i18n" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debuginfo" release="9.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1174</id>
          <title>An update for freeglut is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24258" id="CVE-2024-24258" title="CVE-2024-24258" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24259" id="CVE-2024-24259" title="CVE-2024-24259" type="cve"></reference>
          </references>
          <description>freeglut 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddSubMenu function.(CVE-2024-24258)freeglut through 3.4.0 was discovered to contain a memory leak via the menuEntry variable in the glutAddMenuEntry function.(CVE-2024-24259)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="freeglut-debuginfo" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-debuginfo-3.0.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeglut-help" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-help-3.0.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeglut-devel" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-devel-3.0.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeglut" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-3.0.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeglut-debugsource" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-debugsource-3.0.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeglut" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-3.0.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeglut-debuginfo" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-debuginfo-3.0.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeglut-help" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-help-3.0.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeglut-debugsource" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-debugsource-3.0.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeglut-devel" release="12.oe2203sp1" version="3.0.0">
                         <filename>freeglut-devel-3.0.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1175</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46838" id="CVE-2023-46838" title="CVE-2023-46838" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52340" id="CVE-2023-52340" title="CVE-2023-52340" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0639" id="CVE-2024-0639" title="CVE-2024-0639" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0841" id="CVE-2024-0841" title="CVE-2024-0841" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1086" id="CVE-2024-1086" title="CVE-2024-1086" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23849" id="CVE-2024-23849" title="CVE-2024-23849" type="cve"></reference>
          </references>
          <description>Transmit requests in Xen&#39;s virtual network protocol can consist ofmultiple parts.  While not really useful, except for the initial partany of them may be of zero length, i.e. carry no data at all.  Besides acertain initial portion of the to be transferred data, these parts aredirectly translated into what Linux calls SKB fragments.  Such convertedrequest parts can, when for a particular SKB they are all of lengthzero, lead to a de-reference of NULL in core networking code.(CVE-2023-46838)A flaw in the routing table size was found in the ICMPv6 handling of &#34;Packet Too Big&#34;. The size of the routing table is regulated by periodic garbage collection. However, with &#34;Packet Too Big Messages&#34; it is possible to exceed the routing table size and garbage collector threshold. A user located in the local network or with a high bandwidth connection can increase the CPU usage of the server that accepts IPV6 connections up to 95%.(CVE-2023-52340)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-0639)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-2024-0841)A use-after-free vulnerability in the Linux kernel&#39;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-1086)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-2024-23849)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-debugsource" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.64.0.144.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-tools-devel" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.64.0.144.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.64.0.144.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1182</id>
          <title>An update for runc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21626" id="CVE-2024-21626" title="CVE-2024-21626" type="cve"></reference>
          </references>
          <description>runc is a CLI tool for spawning and running containers on Linux according to the OCI specification. In runc 1.1.11 and earlier, due to an internal file descriptor leak, an attacker could cause a newly-spawned container process (from runc exec) to have a working directory in the host filesystem namespace, allowing for a container escape by giving access to the host filesystem (&#34;attack 2&#34;). The same attack could be used by a malicious image to allow a container process to gain access to the host filesystem through runc run (&#34;attack 1&#34;). Variants of attacks 1 and 2 could be also be used to overwrite semi-arbitrary host binaries, allowing for complete container escapes (&#34;attack 3a&#34; and &#34;attack 3b&#34;). runc 1.1.12 includes patches for this issue.(CVE-2024-21626)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="docker-runc" release="23.oe2203sp1" version="1.1.3">
                         <filename>docker-runc-1.1.3-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="docker-runc" release="23.oe2203sp1" version="1.1.3">
                         <filename>docker-runc-1.1.3-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1183</id>
          <title>An update for libxml2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25062" id="CVE-2024-25062" title="CVE-2024-25062" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-25062)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libxml2-debugsource" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-2.9.14-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-libxml2" release="10.oe2203sp1" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debuginfo" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-devel" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libxml2-help" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-help-2.9.14-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libxml2" release="10.oe2203sp1" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-2.9.14-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-devel" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debugsource" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debuginfo" release="10.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1187</id>
          <title>An update for shim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
          </references>
          <description>A security vulnerability has been identified in all supported versionsof OpenSSL related to the verification of X.509 certificate chainsthat include policy constraints.  Attackers may be able to exploit thisvulnerability by creating a malicious certificate chain that triggersexponential 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 passingthe `-policy&#39; argument to the command line utilities or by calling the`X509_VERIFY_PARAM_set1_policies()&#39; function.(CVE-2023-0464)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="shim" release="16.oe2203sp1" version="15.6">
                         <filename>shim-15.6-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debuginfo" release="16.oe2203sp1" version="15.6">
                         <filename>shim-debuginfo-15.6-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debugsource" release="16.oe2203sp1" version="15.6">
                         <filename>shim-debugsource-15.6-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="shim" release="16.oe2203sp1" version="15.6">
                         <filename>shim-15.6-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1188</id>
          <title>An update for libgit2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24577" id="CVE-2024-24577" title="CVE-2024-24577" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-24577)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libgit2-debugsource" release="3.oe2203sp1" version="1.3.2">
                         <filename>libgit2-debugsource-1.3.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgit2-debuginfo" release="3.oe2203sp1" version="1.3.2">
                         <filename>libgit2-debuginfo-1.3.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgit2-devel" release="3.oe2203sp1" version="1.3.2">
                         <filename>libgit2-devel-1.3.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgit2" release="3.oe2203sp1" version="1.3.2">
                         <filename>libgit2-1.3.2-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgit2-devel" release="3.oe2203sp1" version="1.3.2">
                         <filename>libgit2-devel-1.3.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgit2-debugsource" release="3.oe2203sp1" version="1.3.2">
                         <filename>libgit2-debugsource-1.3.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgit2" release="3.oe2203sp1" version="1.3.2">
                         <filename>libgit2-1.3.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgit2-debuginfo" release="3.oe2203sp1" version="1.3.2">
                         <filename>libgit2-debuginfo-1.3.2-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1189</id>
          <title>An update for varnish is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44487" id="CVE-2023-44487" title="CVE-2023-44487" type="cve"></reference>
          </references>
          <description>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-2023-44487)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="varnish" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-7.4.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-devel" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-devel-7.4.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debuginfo" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-debuginfo-7.4.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debugsource" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-debugsource-7.4.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="varnish-help" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-help-7.4.2-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debuginfo" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-debuginfo-7.4.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-7.4.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debugsource" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-debugsource-7.4.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-devel" release="1.oe2203sp1" version="7.4.2">
                         <filename>varnish-devel-7.4.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1190</id>
          <title>An update for ansible is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0690" id="CVE-2024-0690" title="CVE-2024-0690" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-0690)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="ansible" release="4.oe2203sp1" version="2.9.27">
                         <filename>ansible-2.9.27-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ansible-help" release="4.oe2203sp1" version="2.9.27">
                         <filename>ansible-help-2.9.27-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1192</id>
          <title>An update for mod_auth_openidc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24814" id="CVE-2024-24814" title="CVE-2024-24814" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-24814)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mod_auth_openidc-debugsource" release="1.oe2203sp1" version="2.4.15.3">
                         <filename>mod_auth_openidc-debugsource-2.4.15.3-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_auth_openidc" release="1.oe2203sp1" version="2.4.15.3">
                         <filename>mod_auth_openidc-2.4.15.3-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_auth_openidc-debuginfo" release="1.oe2203sp1" version="2.4.15.3">
                         <filename>mod_auth_openidc-debuginfo-2.4.15.3-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc-debugsource" release="1.oe2203sp1" version="2.4.15.3">
                         <filename>mod_auth_openidc-debugsource-2.4.15.3-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc" release="1.oe2203sp1" version="2.4.15.3">
                         <filename>mod_auth_openidc-2.4.15.3-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_auth_openidc-debuginfo" release="1.oe2203sp1" version="2.4.15.3">
                         <filename>mod_auth_openidc-debuginfo-2.4.15.3-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1195</id>
          <title>An update for python-jwcrypto is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6681" id="CVE-2023-6681" title="CVE-2023-6681" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-6681)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-jwcrypto" release="2.oe2203sp1" version="1.4.2">
                         <filename>python3-jwcrypto-1.4.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1199</id>
          <title>An update for indent is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0911" id="CVE-2024-0911" title="CVE-2024-0911" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-0911)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="indent-debugsource" release="30.oe2203sp1" version="2.2.11">
                         <filename>indent-debugsource-2.2.11-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="indent" release="30.oe2203sp1" version="2.2.11">
                         <filename>indent-2.2.11-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="indent-debuginfo" release="30.oe2203sp1" version="2.2.11">
                         <filename>indent-debuginfo-2.2.11-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="indent-help" release="30.oe2203sp1" version="2.2.11">
                         <filename>indent-help-2.2.11-30.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="indent" release="30.oe2203sp1" version="2.2.11">
                         <filename>indent-2.2.11-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="indent-debugsource" release="30.oe2203sp1" version="2.2.11">
                         <filename>indent-debugsource-2.2.11-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="indent-debuginfo" release="30.oe2203sp1" version="2.2.11">
                         <filename>indent-debuginfo-2.2.11-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1200</id>
          <title>An update for libuv is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24806" id="CVE-2024-24806" title="CVE-2024-24806" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-24806)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="libuv" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-1.42.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libuv-debuginfo" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-debuginfo-1.42.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libuv-debugsource" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-debugsource-1.42.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libuv-devel" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-devel-1.42.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="libuv-help" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-help-1.42.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libuv-devel" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-devel-1.42.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libuv" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-1.42.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libuv-debuginfo" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-debuginfo-1.42.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libuv-debugsource" release="8.oe2203sp1" version="1.42.0">
                         <filename>libuv-debugsource-1.42.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1201</id>
          <title>An update for rust is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24577" id="CVE-2024-24577" title="CVE-2024-24577" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-24577)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="rust" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-debuginfo" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-debuginfo-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rustfmt" release="3.oe2203sp1" version="1.60.0">
                         <filename>rustfmt-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-help" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-help-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-analysis" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-analysis-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cargo" release="3.oe2203sp1" version="1.60.0">
                         <filename>cargo-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-debugsource" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-debugsource-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-std-static" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-std-static-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clippy" release="3.oe2203sp1" version="1.60.0">
                         <filename>clippy-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rls" release="3.oe2203sp1" version="1.60.0">
                         <filename>rls-1.60.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-src" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-src-1.60.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-lldb" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-lldb-1.60.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-debugger-common" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-debugger-common-1.60.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-gdb" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-gdb-1.60.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rustfmt" release="3.oe2203sp1" version="1.60.0">
                         <filename>rustfmt-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-analysis" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-analysis-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-debuginfo" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-debuginfo-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cargo" release="3.oe2203sp1" version="1.60.0">
                         <filename>cargo-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-std-static" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-std-static-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clippy" release="3.oe2203sp1" version="1.60.0">
                         <filename>clippy-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="rust-help" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-help-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-debugsource" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-debugsource-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust" release="3.oe2203sp1" version="1.60.0">
                         <filename>rust-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rls" release="3.oe2203sp1" version="1.60.0">
                         <filename>rls-1.60.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1207</id>
          <title>An update for openvswitch is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3966" id="CVE-2023-3966" title="CVE-2023-3966" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-3966)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openvswitch-debugsource" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-devel" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-debuginfo" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-help" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-help" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debuginfo" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debugsource" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-devel" release="7.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1209</id>
          <title>An update for graphviz is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-02-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46045" id="CVE-2023-46045" title="CVE-2023-46045" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-46045)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="graphviz-debuginfo" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-debuginfo-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-docs" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-docs-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-devel" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-devel-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-lua" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-lua-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-graphs" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-graphs-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-tcl" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-tcl-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-python3" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-python3-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-java" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-java-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-gd" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-gd-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-ocaml" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-ocaml-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-guile" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-guile-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-debugsource" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-debugsource-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-perl" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-perl-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="graphviz-ruby" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-ruby-2.48.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-graphs" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-graphs-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-lua" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-lua-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-perl" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-perl-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-guile" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-guile-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-ruby" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-ruby-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-devel" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-devel-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-python3" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-python3-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-debuginfo" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-debuginfo-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-ocaml" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-ocaml-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-docs" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-docs-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-debugsource" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-debugsource-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-tcl" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-tcl-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-java" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-java-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="graphviz-gd" release="5.oe2203sp1" version="2.48.0">
                         <filename>graphviz-gd-2.48.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1210</id>
          <title>An update for unbound is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50387" id="CVE-2023-50387" title="CVE-2023-50387" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1488" id="CVE-2024-1488" title="CVE-2024-1488" type="cve"></reference>
          </references>
          <description>Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the &#34;KeyTrap&#34; issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.(CVE-2023-50387)The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the &#34;NSEC3&#34; issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.(CVE-2023-50868)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.(CVE-2024-1488)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="unbound" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-1.13.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-help" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-help-1.13.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debuginfo" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-devel" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-devel-1.13.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unbound" release="10.oe2203sp1" version="1.13.2">
                         <filename>python3-unbound-1.13.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-libs" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-libs-1.13.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debugsource" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unbound" release="10.oe2203sp1" version="1.13.2">
                         <filename>python3-unbound-1.13.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-1.13.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debugsource" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debuginfo" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-devel" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-devel-1.13.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-help" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-help-1.13.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-libs" release="10.oe2203sp1" version="1.13.2">
                         <filename>unbound-libs-1.13.2-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1212</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3479" id="CVE-2022-3479" title="CVE-2022-3479" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-3479)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox-debuginfo" release="5.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="5.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox" release="5.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="5.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="5.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="5.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1216</id>
          <title>An update for OpenEXR is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5841" id="CVE-2023-5841" title="CVE-2023-5841" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-5841)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="OpenEXR" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-3.1.5-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenEXR-libs" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-libs-3.1.5-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenEXR-debuginfo" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-debuginfo-3.1.5-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenEXR-debugsource" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-debugsource-3.1.5-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenEXR-devel" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-devel-3.1.5-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR-debugsource" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-debugsource-3.1.5-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-3.1.5-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR-debuginfo" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-debuginfo-3.1.5-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR-devel" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-devel-3.1.5-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR-libs" release="2.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-libs-3.1.5-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1219</id>
          <title>An update for less is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48624" id="CVE-2022-48624" title="CVE-2022-48624" type="cve"></reference>
          </references>
          <description>close_altfile in filename.c in less before 606 omits shell_quote calls for LESSCLOSE.(CVE-2022-48624)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="less-debugsource" release="5.oe2203sp1" version="590">
                         <filename>less-debugsource-590-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="less-debuginfo" release="5.oe2203sp1" version="590">
                         <filename>less-debuginfo-590-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="less" release="5.oe2203sp1" version="590">
                         <filename>less-590-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="less-help" release="5.oe2203sp1" version="590">
                         <filename>less-help-590-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less" release="5.oe2203sp1" version="590">
                         <filename>less-590-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less-debuginfo" release="5.oe2203sp1" version="590">
                         <filename>less-debuginfo-590-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less-debugsource" release="5.oe2203sp1" version="590">
                         <filename>less-debugsource-590-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1224</id>
          <title>An update for shim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
          </references>
          <description>Applications that use a non-default option when verifying certificates may bevulnerable to an attack from a malicious CA to circumvent certain checks.Invalid certificate policies in leaf certificates are silently ignored byOpenSSL and other certificate policy checks are skipped for that certificate.A malicious CA could use this to deliberately assert invalid certificate policiesin order to circumvent policy checking on the certificate altogether.Policy processing is disabled by default but can be enabled by passingthe `-policy&#39; argument to the command line utilities or by calling the`X509_VERIFY_PARAM_set1_policies()&#39; function.(CVE-2023-0465)Issue summary: Processing some specially crafted ASN.1 object identifiers ordata containing them may be very slow.Impact summary: Applications that use OBJ_obj2txt() directly, or use any ofthe OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no messagesize limit may experience notable to very long delays when processing thosemessages, 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 translatean ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSLtype ASN1_OBJECT) to its canonical numeric text form, which are thesub-identifiers of the OBJECT IDENTIFIER in decimal form, separated byperiods.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 hundredsof KiBs), the translation to a decimal number in text may take a very longtime.  The time complexity is O(n^2) with &#39;n&#39; being the size of thesub-identifiers in bytes (*).With OpenSSL 3.0, support to fetch cryptographic algorithms using names /identifiers in string form was introduced.  This includes using OBJECTIDENTIFIERs in canonical numeric text form as identifiers for fetchingalgorithms.Such OBJECT IDENTIFIERs may be received through the ASN.1 structureAlgorithmIdentifier, which is commonly used in multiple protocols to specifywhat cryptographic algorithm should be used to sign or verify, encrypt ordecrypt, or digest passed data.Applications that call OBJ_obj2txt() directly with untrusted data areaffected, with any version of OpenSSL.  If the use is for the mere purposeof 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.509certificates, including simple things like verifying its signature.The impact on TLS is relatively low, because all versions of OpenSSL have a100KiB limit on the peer&#39;s certificate chain.  Additionally, this onlyimpacts clients, or servers that have explicitly enabled clientauthentication.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 waythat it would cause a Denial of Service, so these versions are considerednot affected by this issue in such a way that it would be cause for concern,and the severity is therefore considered low.(CVE-2023-2650)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 longdelays. Where the key or parameters that are being checked have been obtainedfrom an untrusted source this may lead to a Denial of Service.The function DH_check() performs various checks on DH parameters. One of thosechecks confirms that the modulus (&#39;p&#39; parameter) is not too large. Trying to usea very large modulus is slow and OpenSSL will not normally use a modulus whichis over 10,000 bits in length.However the DH_check() function checks numerous aspects of the key or parametersthat have been supplied. Some of those checks use the supplied modulus valueeven if it has already been found to be too large.An application that calls DH_check() and supplies a key or parameters obtainedfrom 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() andEVP_PKEY_param_check().Also vulnerable are the OpenSSL dhparam and pkeyparam command line applicationswhen using the &#39;-check&#39; 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: Processing a maliciously formatted PKCS12 file may lead OpenSSLto crash leading to a potential Denial of Service attackImpact summary: Applications loading files in the PKCS12 format from untrustedsources might terminate abruptly.A file in PKCS12 format can contain certificates and keys and may come from anuntrusted source. The PKCS12 specification allows certain fields to be NULL, butOpenSSL does not correctly check for this case. This can lead to a NULL pointerdereference that results in OpenSSL crashing. If an application processes PKCS12files from an untrusted source using the OpenSSL APIs then that application willbe 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 thisfunction 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.(CVE-2024-0727)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="shim" release="17.oe2203sp1" version="15.6">
                         <filename>shim-15.6-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debuginfo" release="17.oe2203sp1" version="15.6">
                         <filename>shim-debuginfo-15.6-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="shim-debugsource" release="17.oe2203sp1" version="15.6">
                         <filename>shim-debugsource-15.6-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="shim" release="17.oe2203sp1" version="15.6">
                         <filename>shim-15.6-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1228</id>
          <title>An update for fontforge is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25081" id="CVE-2024-25081" title="CVE-2024-25081" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25082" id="CVE-2024-25082" title="CVE-2024-25082" type="cve"></reference>
          </references>
          <description>Splinefont in FontForge through 20230101 allows command injection via crafted filenames.(CVE-2024-25081)Splinefont in FontForge through 20230101 allows command injection via crafted archives or compressed files.(CVE-2024-25082)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="fontforge-debuginfo" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-debuginfo-20200314-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fontforge" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-20200314-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fontforge-debugsource" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-debugsource-20200314-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fontforge-devel" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-devel-20200314-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="fontforge-help" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-help-20200314-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fontforge-debuginfo" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-debuginfo-20200314-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fontforge" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-20200314-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fontforge-devel" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-devel-20200314-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fontforge-debugsource" release="8.oe2203sp1" version="20200314">
                         <filename>fontforge-debugsource-20200314-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1229</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24680" id="CVE-2024-24680" title="CVE-2024-24680" type="cve"></reference>
          </references>
          <description>An issue was discovered in Django 3.2 before 3.2.24, 4.2 before 4.2.10, and Django 5.0 before 5.0.2. The intcomma template filter was subject to a potential denial-of-service attack when used with very long strings.(CVE-2024-24680)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-Django" release="9.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-django-help" release="9.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-9.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1232</id>
          <title>An update for xerces-c is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2018-1311" id="CVE-2018-1311" title="CVE-2018-1311" type="cve"></reference>
          </references>
          <description>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.(CVE-2018-1311)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xerces-c-devel" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-devel-3.2.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xerces-c-debugsource" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-debugsource-3.2.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xerces-c" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-3.2.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xerces-c-debuginfo" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-debuginfo-3.2.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xerces-c-help" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-help-3.2.2-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xerces-c-devel" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-devel-3.2.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xerces-c" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-3.2.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xerces-c-debuginfo" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-debuginfo-3.2.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xerces-c-debugsource" release="5.oe2203sp1" version="3.2.2">
                         <filename>xerces-c-debugsource-3.2.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1237</id>
          <title>An update for postgresql-jdbc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1597" id="CVE-2024-1597" title="CVE-2024-1597" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-1597)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="postgresql-jdbc-help" release="3.oe2203sp1" version="42.4.1">
                         <filename>postgresql-jdbc-help-42.4.1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-jdbc" release="3.oe2203sp1" version="42.4.1">
                         <filename>postgresql-jdbc-42.4.1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-jdbc-javadoc" release="3.oe2203sp1" version="42.4.1">
                         <filename>postgresql-jdbc-javadoc-42.4.1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1238</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0464" id="CVE-2023-0464" title="CVE-2023-0464" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0465" id="CVE-2023-0465" title="CVE-2023-0465" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0466" id="CVE-2023-0466" title="CVE-2023-0466" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2650" id="CVE-2023-2650" title="CVE-2023-2650" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3446" id="CVE-2023-3446" title="CVE-2023-3446" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0727" id="CVE-2024-0727" title="CVE-2024-0727" type="cve"></reference>
          </references>
          <description>A security vulnerability has been identified in all supported versionsof OpenSSL related to the verification of X.509 certificate chainsthat include policy constraints.  Attackers may be able to exploit thisvulnerability by creating a malicious certificate chain that triggersexponential 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 passingthe `-policy&#39; argument to the command line utilities or by calling the`X509_VERIFY_PARAM_set1_policies()&#39; function.(CVE-2023-0464)Applications that use a non-default option when verifying certificates may bevulnerable to an attack from a malicious CA to circumvent certain checks.Invalid certificate policies in leaf certificates are silently ignored byOpenSSL and other certificate policy checks are skipped for that certificate.A malicious CA could use this to deliberately assert invalid certificate policiesin order to circumvent policy checking on the certificate altogether.Policy processing is disabled by default but can be enabled by passingthe `-policy&#39; argument to the command line utilities or by calling the`X509_VERIFY_PARAM_set1_policies()&#39; function.(CVE-2023-0465)The function X509_VERIFY_PARAM_add0_policy() is documented toimplicitly enable the certificate policy check when doing certificateverification. However the implementation of the function does notenable the check which allows certificates with invalid or incorrectpolicies to pass the certificate verification.As suddenly enabling the policy check could break existing deployments it wasdecided to keep the existing behavior of the X509_VERIFY_PARAM_add0_policy()function.Instead the applications that require OpenSSL to perform certificatepolicy check need to use X509_VERIFY_PARAM_set1_policies() or explicitlyenable the policy check by calling X509_VERIFY_PARAM_set_flags() withthe X509_V_FLAG_POLICY_CHECK flag argument.Certificate policy checks are disabled by default in OpenSSL and are notcommonly used by applications.(CVE-2023-0466)Issue summary: Processing some specially crafted ASN.1 object identifiers ordata containing them may be very slow.Impact summary: Applications that use OBJ_obj2txt() directly, or use any ofthe OpenSSL subsystems OCSP, PKCS7/SMIME, CMS, CMP/CRMF or TS with no messagesize limit may experience notable to very long delays when processing thosemessages, 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 translatean ASN.1 OBJECT IDENTIFIER given in DER encoding form (using the OpenSSLtype ASN1_OBJECT) to its canonical numeric text form, which are thesub-identifiers of the OBJECT IDENTIFIER in decimal form, separated byperiods.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 hundredsof KiBs), the translation to a decimal number in text may take a very longtime.  The time complexity is O(n^2) with &#39;n&#39; being the size of thesub-identifiers in bytes (*).With OpenSSL 3.0, support to fetch cryptographic algorithms using names /identifiers in string form was introduced.  This includes using OBJECTIDENTIFIERs in canonical numeric text form as identifiers for fetchingalgorithms.Such OBJECT IDENTIFIERs may be received through the ASN.1 structureAlgorithmIdentifier, which is commonly used in multiple protocols to specifywhat cryptographic algorithm should be used to sign or verify, encrypt ordecrypt, or digest passed data.Applications that call OBJ_obj2txt() directly with untrusted data areaffected, with any version of OpenSSL.  If the use is for the mere purposeof 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.509certificates, including simple things like verifying its signature.The impact on TLS is relatively low, because all versions of OpenSSL have a100KiB limit on the peer&#39;s certificate chain.  Additionally, this onlyimpacts clients, or servers that have explicitly enabled clientauthentication.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 waythat it would cause a Denial of Service, so these versions are considerednot affected by this issue in such a way that it would be cause for concern,and the severity is therefore considered low.(CVE-2023-2650)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 longdelays. Where the key or parameters that are being checked have been obtainedfrom an untrusted source this may lead to a Denial of Service.The function DH_check() performs various checks on DH parameters. One of thosechecks confirms that the modulus (&#39;p&#39; parameter) is not too large. Trying to usea very large modulus is slow and OpenSSL will not normally use a modulus whichis over 10,000 bits in length.However the DH_check() function checks numerous aspects of the key or parametersthat have been supplied. Some of those checks use the supplied modulus valueeven if it has already been found to be too large.An application that calls DH_check() and supplies a key or parameters obtainedfrom 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() andEVP_PKEY_param_check().Also vulnerable are the OpenSSL dhparam and pkeyparam command line applicationswhen using the &#39;-check&#39; 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: Processing a maliciously formatted PKCS12 file may lead OpenSSLto crash leading to a potential Denial of Service attackImpact summary: Applications loading files in the PKCS12 format from untrustedsources might terminate abruptly.A file in PKCS12 format can contain certificates and keys and may come from anuntrusted source. The PKCS12 specification allows certain fields to be NULL, butOpenSSL does not correctly check for this case. This can lead to a NULL pointerdereference that results in OpenSSL crashing. If an application processes PKCS12files from an untrusted source using the OpenSSL APIs then that application willbe 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 thisfunction 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.(CVE-2024-0727)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debugsource" release="14.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debuginfo" release="14.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="14.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="14.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="14.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="14.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="14.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="14.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="14.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="14.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1242</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-01"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52435" id="CVE-2023-52435" title="CVE-2023-52435" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23196" id="CVE-2024-23196" title="CVE-2024-23196" type="cve"></reference>
          </references>
          <description>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 followingcomputation in skb_segment() can reach it quite easily :&#x9;mss = mss * partial_segs;65535 = 3 * 5 * 17 * 257, so many initial values of mss can lead toa bad final result.Make sure to limit segmentation so that the new mss value is smallerthan GSO_BY_FRAGS.[1]general protection fault, probably for non-canonical address 0xdffffc000000000e: 0000 [#1] PREEMPT SMP KASANKASAN: null-ptr-deref in range [0x0000000000000070-0x0000000000000077]CPU: 1 PID: 5079 Comm: syz-executor993 Not tainted 6.7.0-rc4-syzkaller-00141-g1ae4cd3cbdd0 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551Code: 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 00RSP: 0018:ffffc900043473d0 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070RBP: ffffc90004347578 R08: 0000000000000005 R09: 000000000000ffffR10: 000000000000ffff R11: 0000000000000002 R12: ffff888063202ac0R13: 0000000000010000 R14: 000000000000ffff R15: 0000000000000046FS: 0000555556e7e380(0000) GS:ffff8880b9900000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020010000 CR3: 0000000027ee2000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:&lt;TASK&gt;udp6_ufo_fragment+0xa0e/0xd00 net/ipv6/udp_offload.c:109ipv6_gso_segment+0x534/0x17e0 net/ipv6/ip6_offload.c:120skb_mac_gso_segment+0x290/0x610 net/core/gso.c:53__skb_gso_segment+0x339/0x710 net/core/gso.c:124skb_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:4338dev_queue_xmit include/linux/netdevice.h:3134 [inline]packet_xmit+0x257/0x380 net/packet/af_packet.c:276packet_snd net/packet/af_packet.c:3087 [inline]packet_sendmsg+0x24c6/0x5220 net/packet/af_packet.c:3119sock_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:2198do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0x40/0x110 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x63/0x6bRIP: 0033:0x7f8692032aa9Code: 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 48RSP: 002b:00007fff8d685418 EFLAGS: 00000246 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f8692032aa9RDX: 0000000000010048 RSI: 00000000200000c0 RDI: 0000000000000003RBP: 00000000000f4240 R08: 0000000020000540 R09: 0000000000000014R10: 0000000000000000 R11: 0000000000000246 R12: 00007fff8d685480R13: 0000000000000001 R14: 00007fff8d685480 R15: 0000000000000003&lt;/TASK&gt;Modules linked in:---[ end trace 0000000000000000 ]---RIP: 0010:skb_segment+0x181d/0x3f30 net/core/skbuff.c:4551Code: 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 00RSP: 0018:ffffc900043473d0 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000010046 RCX: ffffffff886b1597RDX: 000000000000000e RSI: ffffffff886b2520 RDI: 0000000000000070RBP: ffffc90004347578 R0---truncated---(CVE-2023-52435)A race condition was found in the Linux kernel&#39;s sound/hda  device driver in snd_hdac_regmap_sync() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.(CVE-2024-23196)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="python3-perf-debuginfo" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.65.0.145.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.65.0.145.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.65.0.145.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1248</id>
          <title>An update for atril is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52076" id="CVE-2023-52076" title="CVE-2023-52076" type="cve"></reference>
          </references>
          <description>Atril Document Viewer is the default document reader of the MATE desktop environment for Linux. A path traversal and arbitrary file write vulnerability exists in versions of Atril prior to 1.26.2. This vulnerability is capable of writing arbitrary files anywhere on the filesystem to which the user opening a crafted document has access. The only limitation is that this vulnerability cannot be exploited to overwrite existing files, but that doesn&#39;t stop an attacker from achieving Remote Command Execution on the target system. Version 1.26.2 of Atril contains a patch for this vulnerability.(CVE-2023-52076)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="atril-devel" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-devel-1.22.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="atril" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-1.22.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="atril-debuginfo" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-debuginfo-1.22.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="atril-debugsource" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-debugsource-1.22.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="atril-libs" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-libs-1.22.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril-libs" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-libs-1.22.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril-debuginfo" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-debuginfo-1.22.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-1.22.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril-devel" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-devel-1.22.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril-debugsource" release="3.oe2203sp1" version="1.22.3">
                         <filename>atril-debugsource-1.22.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1250</id>
          <title>An update for containers-common is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32148" id="CVE-2022-32148" title="CVE-2022-32148" type="cve"></reference>
          </references>
          <description>Improper exposure of client IP addresses in net/http before Go 1.17.12 and Go 1.18.4 can be triggered by calling httputil.ReverseProxy.ServeHTTP with a Request.Header map containing a nil value for the X-Forwarded-For header, which causes ReverseProxy to set the client IP as the value of the X-Forwarded-For header.(CVE-2022-32148)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="containers-common" release="2.oe2203sp1" version="1">
                         <filename>containers-common-1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1251</id>
          <title>An update for cri-o is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2995" id="CVE-2022-2995" title="CVE-2022-2995" type="cve"></reference>
          </references>
          <description>Incorrect handling of the supplementary groups in the CRI-O container engine might lead to sensitive information disclosure or possible data modification if an attacker has direct access to the affected container where supplementary groups are used to set access permissions and is able to execute a binary code in that container.(CVE-2022-2995)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cri-o" release="2.oe2203sp1" version="1.23.2">
                         <filename>cri-o-1.23.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cri-o-debuginfo" release="2.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debuginfo-1.23.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cri-o-debugsource" release="2.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debugsource-1.23.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o" release="2.oe2203sp1" version="1.23.2">
                         <filename>cri-o-1.23.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o-debuginfo" release="2.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debuginfo-1.23.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o-debugsource" release="2.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debugsource-1.23.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1252</id>
          <title>An update for json-path is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51074" id="CVE-2023-51074" title="CVE-2023-51074" type="cve"></reference>
          </references>
          <description>json-path v2.8.0 was discovered to contain a stack overflow via the Criteria.parse() method.(CVE-2023-51074)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="json-path-javadoc" release="2.oe2203sp1" version="2.1.0">
                         <filename>json-path-javadoc-2.1.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="json-path" release="2.oe2203sp1" version="2.1.0">
                         <filename>json-path-2.1.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1253</id>
          <title>An update for grub2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1048" id="CVE-2024-1048" title="CVE-2024-1048" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-1048)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64-cdboot" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-cdboot-2.06-41.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-debuginfo" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-debuginfo-2.06-41.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-2.06-41.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-debugsource" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-debugsource-2.06-41.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-extra" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-tools-extra-2.06-41.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-minimal" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-tools-minimal-2.06-41.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-tools-2.06-41.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-aa64-modules" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-modules-2.06-41.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-x64-modules" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-modules-2.06-41.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-help" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-help-2.06-41.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-common" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-common-2.06-41.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-pc-modules" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-pc-modules-2.06-41.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-ia32-modules" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-modules-2.06-41.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-extra" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-tools-extra-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-pc" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-pc-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32-cdboot" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-cdboot-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-efi" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-tools-efi-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debugsource" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-debugsource-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64-cdboot" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-cdboot-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debuginfo" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-debuginfo-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-minimal" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-tools-minimal-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools" release="41.oe2203sp1" version="2.06">
                         <filename>grub2-tools-2.06-41.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1254</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27351" id="CVE-2024-27351" title="CVE-2024-27351" type="cve"></reference>
          </references>
          <description>An inefficient regular expression complexity flaw was found in the Truncator.words function and truncatewords_html filter of Django. This issue may allow an attacker to use a suitably crafted string to cause a denial of service.(CVE-2024-27351)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="10.oe2203sp1" version="3.2.12">
                         <filename>python-django-help-3.2.12-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="10.oe2203sp1" version="3.2.12">
                         <filename>python3-Django-3.2.12-10.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1255</id>
          <title>An update for jsoup is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36033" id="CVE-2022-36033" title="CVE-2022-36033" type="cve"></reference>
          </references>
          <description>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.)(CVE-2022-36033)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jsoup" release="2.oe2203sp1" version="1.14.2">
                         <filename>jsoup-1.14.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1256</id>
          <title>An update for rubygem-yard is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27285" id="CVE-2024-27285" title="CVE-2024-27285" type="cve"></reference>
          </references>
          <description>YARD is a Ruby Documentation tool. The &#34;frames.html&#34; file within the Yard Doc&#39;s generated documentation is vulnerable to Cross-Site Scripting (XSS) attacks due to inadequate sanitization of user input within the JavaScript segment of the &#34;frames.erb&#34; template file.  This vulnerability is fixed in 0.9.36.(CVE-2024-27285)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rubygem-yard" release="3.oe2203sp1" version="0.9.26">
                         <filename>rubygem-yard-0.9.26-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-yard-doc" release="3.oe2203sp1" version="0.9.26">
                         <filename>rubygem-yard-doc-0.9.26-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1257</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1151" id="CVE-2024-1151" title="CVE-2024-1151" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26595" id="CVE-2024-26595" title="CVE-2024-26595" type="cve"></reference>
          </references>
          <description>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-2024-1151)In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix NULL pointer dereference in error pathWhen calling mlxsw_sp_acl_tcam_region_destroy() from an error path afterfailing to attach the region to an ACL group, we hit a NULL pointerdereference upon &#39;region-&gt;group-&gt;tcam&#39; [1].Fix by retrieving the &#39;tcam&#39; 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-2024-26595)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.66.0.146.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.66.0.146.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.66.0.146.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1264</id>
          <title>An update for arm-trusted-firmware is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-08"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49100" id="CVE-2023-49100" title="CVE-2023-49100" type="cve"></reference>
          </references>
          <description>Trusted Firmware-A (TF-A) before 2.10 has a potential read out-of-bounds in the SDEI service. The input parameter passed in register x1 is not validated well enough in the function sdei_interrupt_bind. The parameter is passed to a call to plat_ic_get_interrupt_type. It can be any arbitrary value passing checks in the function plat_ic_is_sgi. A compromised Normal World (Linux kernel) can enable a root-privileged attacker to issue arbitrary SMC calls. Using this primitive, he can control the content of registers x0 through x6, which are used to send parameters to TF-A. Out-of-bounds addresses can be read in the context of TF-A (EL3). Because the read value is never returned to non-secure memory or in registers, no leak is possible. An attacker can still crash TF-A, however.(CVE-2023-49100)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="arm-trusted-firmware-armv8" release="4.oe2203sp1" version="2.3">
                         <filename>arm-trusted-firmware-armv8-2.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1267</id>
          <title>An update for glusterfs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48340" id="CVE-2022-48340" title="CVE-2022-48340" type="cve"></reference>
          </references>
          <description>In Gluster GlusterFS 11.0, there is an xlators/cluster/dht/src/dht-common.c dht_setxattr_mds_cbk use-after-free.(CVE-2022-48340)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libgfchangelog-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libgfchangelog-devel-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-thin-arbiter" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-thin-arbiter-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libglusterd0" release="9.oe2203sp1" version="10.0">
                         <filename>libglusterd0-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfchangelog0" release="9.oe2203sp1" version="10.0">
                         <filename>libgfchangelog0-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfxdr0" release="9.oe2203sp1" version="10.0">
                         <filename>libgfxdr0-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-gluster" release="9.oe2203sp1" version="10.0">
                         <filename>python3-gluster-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-fuse" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-fuse-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-debuginfo" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-debuginfo-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libglusterfs-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libglusterfs-devel-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfrpc0" release="9.oe2203sp1" version="10.0">
                         <filename>libgfrpc0-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-geo-replication" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-geo-replication-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-help" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-help-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-events" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-events-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-cli" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-cli-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-cloudsync-plugins" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-cloudsync-plugins-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-client-xlators" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-client-xlators-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-extra-xlators" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-extra-xlators-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfrpc-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libgfrpc-devel-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-debugsource" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-debugsource-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glusterfs-server" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-server-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfapi0" release="9.oe2203sp1" version="10.0">
                         <filename>libgfapi0-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libglusterfs0" release="9.oe2203sp1" version="10.0">
                         <filename>libglusterfs0-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfxdr-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libgfxdr-devel-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgfapi-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libgfapi-devel-10.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glusterfs-resource-agents" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-resource-agents-10.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfxdr0" release="9.oe2203sp1" version="10.0">
                         <filename>libgfxdr0-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-debuginfo" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-debuginfo-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfchangelog0" release="9.oe2203sp1" version="10.0">
                         <filename>libgfchangelog0-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-thin-arbiter" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-thin-arbiter-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libglusterfs0" release="9.oe2203sp1" version="10.0">
                         <filename>libglusterfs0-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libglusterd0" release="9.oe2203sp1" version="10.0">
                         <filename>libglusterd0-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-extra-xlators" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-extra-xlators-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-client-xlators" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-client-xlators-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-debugsource" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-debugsource-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libglusterfs-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libglusterfs-devel-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfxdr-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libgfxdr-devel-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-cli" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-cli-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-events" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-events-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-fuse" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-fuse-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-server" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-server-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfapi-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libgfapi-devel-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-cloudsync-plugins" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-cloudsync-plugins-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-help" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-help-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfrpc0" release="9.oe2203sp1" version="10.0">
                         <filename>libgfrpc0-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs-geo-replication" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-geo-replication-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-gluster" release="9.oe2203sp1" version="10.0">
                         <filename>python3-gluster-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfchangelog-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libgfchangelog-devel-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glusterfs" release="9.oe2203sp1" version="10.0">
                         <filename>glusterfs-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfrpc-devel" release="9.oe2203sp1" version="10.0">
                         <filename>libgfrpc-devel-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgfapi0" release="9.oe2203sp1" version="10.0">
                         <filename>libgfapi0-10.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1270</id>
          <title>An update for glade is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-36774" id="CVE-2020-36774" title="CVE-2020-36774" type="cve"></reference>
          </references>
          <description>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).(CVE-2020-36774)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glade-debugsource" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-debugsource-3.36.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glade" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-3.36.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glade-debuginfo" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-debuginfo-3.36.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glade-devel" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-devel-3.36.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glade-libs" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-libs-3.36.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glade-help" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-help-3.36.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glade-devel" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-devel-3.36.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glade" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-3.36.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glade-libs" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-libs-3.36.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glade-debugsource" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-debugsource-3.36.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glade-debuginfo" release="3.oe2203sp1" version="3.36.0">
                         <filename>glade-debuginfo-3.36.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1274</id>
          <title>An update for A-Tune-Collector is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24897" id="CVE-2024-24897" title="CVE-2024-24897" type="cve"></reference>
          </references>
          <description>When the get method in the sched.py file in the A-Tune-Collector software package is used to obtain the process ID, shell command combination and injection risks exist. This flaw could lead to remote arbitrary command execution.(CVE-2024-24897)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="atune-collector" release="8.oe2203sp1" version="1.1.0">
                         <filename>atune-collector-1.1.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atune-collector" release="8.oe2203sp1" version="1.1.0">
                         <filename>atune-collector-1.1.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1278</id>
          <title>An update for gala-gopher is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24890" id="CVE-2024-24890" title="CVE-2024-24890" type="cve"></reference>
          </references>
          <description>gala-gopher 1.0.2组件中存在命令注入攻击漏洞(CVE-2024-24890)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gala-gopher-debugsource" release="4.oe2203sp1" version="1.0.2">
                         <filename>gala-gopher-debugsource-1.0.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gala-gopher-debuginfo" release="4.oe2203sp1" version="1.0.2">
                         <filename>gala-gopher-debuginfo-1.0.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gala-gopher" release="4.oe2203sp1" version="1.0.2">
                         <filename>gala-gopher-1.0.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gala-gopher" release="4.oe2203sp1" version="1.0.2">
                         <filename>gala-gopher-1.0.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gala-gopher-debugsource" release="4.oe2203sp1" version="1.0.2">
                         <filename>gala-gopher-debugsource-1.0.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gala-gopher-debuginfo" release="4.oe2203sp1" version="1.0.2">
                         <filename>gala-gopher-debuginfo-1.0.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1280</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45229" id="CVE-2023-45229" title="CVE-2023-45229" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45231" id="CVE-2023-45231" title="CVE-2023-45231" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45234" id="CVE-2023-45234" title="CVE-2023-45234" type="cve"></reference>
          </references>
          <description>EDK2&#39;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-45229)EDK2&#39;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-45231) EDK2&#39;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-45234)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="16.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="16.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="16.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1284</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52436" id="CVE-2023-52436" title="CVE-2023-52436" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52438" id="CVE-2023-52438" title="CVE-2023-52438" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52439" id="CVE-2023-52439" title="CVE-2023-52439" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22099" id="CVE-2024-22099" title="CVE-2024-22099" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23850" id="CVE-2024-23850" title="CVE-2024-23850" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23851" id="CVE-2024-23851" title="CVE-2024-23851" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26583" id="CVE-2024-26583" title="CVE-2024-26583" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:f2fs: explicitly null-terminate the xattr listWhen setting an xattr, explicitly null-terminate the xattr list.  Thiseliminates the fragile assumption that the unused xattr space is alwayszeroed.(CVE-2023-52436)In the Linux kernel, the following vulnerability has been resolved:binder: fix use-after-free in shinker&#39;s callbackThe mmap read lock is used during the shrinker&#39;s callback, which meansthat using alloc-&gt;vma pointer isn&#39;t safe as it can race with munmap().As of commit dd2283f2605e (&#34;mm: mmap: zap pages with read mmap_sem inmunmap&#34;) the mmap lock is downgraded after the vma has been isolated.I was able to reproduce this issue by manually adding some delays andtriggering page reclaiming through the shrinker&#39;s debug sysfs. Thefollowing 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/0x7cFix this issue by performing instead a vma_lookup() which will fail tofind the vma that was isolated before the mmap lock downgrade. Note thatthis option has better performance than upgrading to a mmap write lockwhich would increase contention. Plus, mmap_write_trylock() has beenrecently removed anyway.(CVE-2023-52438)In the Linux kernel, the following vulnerability has been resolved:uio: Fix use-after-free in uio_opencore-1&#x9;&#x9;&#x9;&#x9;core-2-------------------------------------------------------uio_unregister_device&#x9;&#x9;uio_open&#x9;&#x9;&#x9;&#x9;idev = idr_find()device_unregister(&amp;idev-&gt;dev)put_device(&amp;idev-&gt;dev)uio_device_release&#x9;&#x9;&#x9;&#x9;get_device(&amp;idev-&gt;dev)kfree(idev)uio_free_minor(minor)&#x9;&#x9;&#x9;&#x9;uio_release&#x9;&#x9;&#x9;&#x9;put_device(&amp;idev-&gt;dev)&#x9;&#x9;&#x9;&#x9;kfree(idev)-------------------------------------------------------In the core-1 uio_unregister_device(), the device_unregister will kfreeidev when the idev-&gt;dev kobject ref is 1. But after core-1device_unregister, put_device and before doing kfree, the core-2 mayget_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 withminor_lock.(CVE-2023-52439)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-22099)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-2024-23850)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-2024-23851)In the Linux kernel, the following vulnerability has been resolved:tls: fix race between async notify and socket closeThe 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 waywe can depend solely on the atomic ref counter forsynchronization.Don&#39;t futz with reiniting the completion, either, we are nowtightly controlling when completion fires.(CVE-2024-26583)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.67.0.147.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="3" arch="x86_64" name="python3-perf" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.67.0.147.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.67.0.147.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1290</id>
          <title>An update for iSulad is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-33632" id="CVE-2021-33632" title="CVE-2021-33632" type="cve"></reference>
          </references>
          <description>在isulad服务初始化阶段，会进行临时文件的正确性检查，如果检查不通过则重新创建文件，在检查与创建之间，存在一个条件竞争问题，攻击者可以通过利用该漏洞进行提权。(CVE-2021-33632)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iSulad" release="16.oe2203sp1" version="2.0.18">
                         <filename>iSulad-2.0.18-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iSulad-debuginfo" release="16.oe2203sp1" version="2.0.18">
                         <filename>iSulad-debuginfo-2.0.18-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iSulad-debugsource" release="16.oe2203sp1" version="2.0.18">
                         <filename>iSulad-debugsource-2.0.18-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iSulad-debuginfo" release="16.oe2203sp1" version="2.0.18">
                         <filename>iSulad-debuginfo-2.0.18-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iSulad" release="16.oe2203sp1" version="2.0.18">
                         <filename>iSulad-2.0.18-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iSulad-debugsource" release="16.oe2203sp1" version="2.0.18">
                         <filename>iSulad-debugsource-2.0.18-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1293</id>
          <title>An update for aops-zeus is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-15"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24899" id="CVE-2024-24899" title="CVE-2024-24899" type="cve"></reference>
          </references>
          <description>In aops-zeus software versions 1.2.0~1.4.1, there is a vulnerability in the plugin management command of the zeus/conf/constant file. Through this vulnerability, an attacker can implant arbitrary commands to be executed on the remote host, which may cause the remote host system to crash, suffering serious consequences of security threats and losses.(CVE-2024-24899)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="aops-zeus" release="5.oe2203sp1" version="v1.2.0">
                         <filename>aops-zeus-v1.2.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="aops-zeus" release="5.oe2203sp1" version="v1.2.0">
                         <filename>aops-zeus-v1.2.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1295</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38575" id="CVE-2023-38575" title="CVE-2023-38575" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39368" id="CVE-2023-39368" title="CVE-2023-39368" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-38575)Protection mechanism failure of bus lock regulator for some Intel(R) Processors may allow an unauthenticated user to potentially enable denial of service via network access.(CVE-2023-39368)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="1.oe2203sp1" version="20240312">
                         <filename>microcode_ctl-20240312-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1299</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46987" id="CVE-2021-46987" title="CVE-2021-46987" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52447" id="CVE-2023-52447" title="CVE-2023-52447" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52448" id="CVE-2023-52448" title="CVE-2023-52448" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52449" id="CVE-2023-52449" title="CVE-2023-52449" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52452" id="CVE-2023-52452" title="CVE-2023-52452" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:btrfs: fix deadlock when cloning inline extents and using qgroupsThere are a few exceptional cases where cloning an inline extent needs tocopy the inline extent data into a page of the destination inode.When this happens, we end up starting a transaction while having a dirtypage for the destination inode and while having the range locked in thedestination&#39;s inode iotree too. Because when reserving metadata spacefor a transaction we may need to flush existing delalloc in case there isnot enough free space, we have a mechanism in place to prevent a deadlock,which was introduced in commit 3d45f221ce627d (&#34;btrfs: fix deadlock whencloning inline extent and low on free metadata space&#34;).However when using qgroups, a transaction also reserves metadata qgroupspace, which can also result in flushing delalloc in case there is notenough available space at the moment. When this happens we deadlock, sinceflushing delalloc requires locking the file range in the inode&#39;s iotreeand the range was already locked at the very beginning of the cloneoperation, 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-2021-46987)In the Linux kernel, the following vulnerability has been resolved:bpf: Defer the free of inner map when necessaryWhen updating or deleting an inner map in map array or map htab, the mapmay still be accessed by non-sleepable program or sleepable program.However bpf_map_fd_put_ptr() decreases the ref-counter of the inner mapdirectly through bpf_map_put(), if the ref-counter is the last one(which is true for most cases), the inner map will be freed byops-&gt;map_free() in a kworker. But for now, most .map_free() callbacksdon&#39;t use synchronize_rcu() or its variants to wait for the elapse of aRCU grace period, so after the invocation of ops-&gt;map_free completes,the bpf program which is accessing the inner map may incuruse-after-free problem.Fix the free of inner map by invoking bpf_map_free_deferred() after bothone RCU grace period and one tasks trace RCU grace period if the innermap has been removed from the outer map before. The deferment isaccomplished by using call_rcu() or call_rcu_tasks_trace() whenreleasing the last ref-counter of bpf map. The newly-added rcu_headfield in bpf_map shares the same storage space with work field toreduce the size of bpf_map.(CVE-2023-52447)In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix kernel NULL pointer dereference in gfs2_rgrp_dumpSyzkaller has reported a NULL pointer dereference when accessingrgd-&gt;rd_rgl in gfs2_rgrp_dump().  This can happen when creatingrgd-&gt;rd_gl fails in read_rindex_entry().  Add a NULL pointer check ingfs2_rgrp_dump() to prevent that.(CVE-2023-52448)In the Linux kernel, the following vulnerability has been resolved:mtd: Fix gluebi NULL pointer dereference caused by ftl notifierIf both ftl.ko and gluebi.ko are loaded, the notifier of ftltriggers 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 - NULLDetailed 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 theftl_add_mtd() process, which leads to NULL pointer dereference.The solution for the gluebi module is to run jffs2 on the UBIvolume without considering working with ftl or mtdblock [2].Therefore, this problem can be avoided by preventing gluebi fromcreating the mtdblock device after creating mtd partition of thetype MTD_UBIVOLUME.(CVE-2023-52449)In the Linux kernel, the following vulnerability has been resolved:bpf: Fix accesses to uninit stack slotsPrivileged programs are supposed to be able to read uninitialized stackmemory (ever since 6715df8d5) but, before this patch, these accesseswere permitted inconsistently. In particular, accesses were permittedabove state-&gt;allocated_stack, but not below it. In other words, if thestack was already &#34;large enough&#34;, the access was permitted, butotherwise the access was rejected instead of being allowed to &#34;grow thestack&#34;. 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 teststhat were relying on the old rejection had to change; all of them werechanged to add also run unprivileged, in which case the old behaviorpersists. One tests couldn&#39;t be updated - global_func16 - because itcan&#39;t run unprivileged for other reasons.This patch also fixes the tracking of the stack size for variable-offsetreads. This second fix is bundled in the same commit as the first onebecause they&#39;re inter-related. Before this patch, writes to the stackusing registers containing a variable offset (as opposed to registerswith fixed, known values) were not properly contributing to thefunction&#39;s needed stack size. As a result, it was possible for a programto verify, but then to attempt to read out-of-bounds data at runtimebecause a too small stack had been allocated for it.Each function tracks the size of the stack it needs inbpf_subprog_info.stack_depth, which is maintained byupdate_stack_depth(). For regular memory accesses, check_mem_access()was calling update_state_depth() but it was passing in only the fixedpart of the offset register, ignoring the variable offset. This wasincorrect; the minimum possible value of that register should be usedinstead.This tracking is now fixed by centralizing the tracking of stack size ingrow_stack_state(), and by lifting the calls to grow_stack_state() tocheck_stack_access_within_bounds() as suggested by Andrii. The code isnow simpler and more convincingly tracks the correct maximum stack size.check_stack_range_initialized() can now rely on enough stack having beenallocated for the access; this helps with the fix for the first issue.A few tests were changed to also check the stack depth computation. Theone that fails without this patch is verifier_var_off:stack_write_priv_vs_unpriv.(CVE-2023-52452)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.68.0.148.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="perf-debuginfo" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-source" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.68.0.148.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.68.0.148.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1302</id>
          <title>An update for docker is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24557" id="CVE-2024-24557" title="CVE-2024-24557" type="cve"></reference>
          </references>
          <description>Moby is an open-source project created by Docker to enable software containerization. The classic builder cache system is prone to cache poisoning if the image is built FROM scratch. Also, changes to some instructions (most important being HEALTHCHECK and ONBUILD) would not cause a cache miss. An attacker with the knowledge of the Dockerfile someone is using could poison their cache by making them pull a specially crafted image that would be considered as a valid cache candidate for some build steps. 23.0+ users are only affected if they explicitly opted out of Buildkit (DOCKER_BUILDKIT=0 environment variable) or are using the /build API endpoint. All users on versions older than 23.0 could be impacted. Image build API endpoint (/build) and ImageBuild function from github.com/docker/docker/client is also affected as it the uses classic builder by default. Patches are included in 24.0.9 and 25.0.2 releases.(CVE-2024-24557)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="docker-engine-debuginfo" release="333.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-333.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine" release="333.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-333.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debugsource" release="333.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-333.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debugsource" release="333.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-333.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine" release="333.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-333.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debuginfo" release="333.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-333.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1306</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45289" id="CVE-2023-45289" title="CVE-2023-45289" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45290" id="CVE-2023-45290" title="CVE-2023-45290" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24783" id="CVE-2024-24783" title="CVE-2024-24783" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24785" id="CVE-2024-24785" title="CVE-2024-24785" type="cve"></reference>
          </references>
          <description>When following an HTTP redirect to a domain which is not a subdomain match or exact match of the initial domain, an http.Client does not forward sensitive headers such as &#34;Authorization&#34; or &#34;Cookie&#34;. For example, a redirect from foo.com to www.foo.com will forward the Authorization header, but a redirect to bar.com will not. A maliciously crafted HTTP redirect could cause sensitive headers to be unexpectedly forwarded.(CVE-2023-45289)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-2023-45290)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-24783)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-24785)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="28.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="28.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-28.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="28.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-28.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="28.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1312</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3019" id="CVE-2023-3019" title="CVE-2023-3019" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6683" id="CVE-2023-6683" title="CVE-2023-6683" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6693" id="CVE-2023-6693" title="CVE-2023-6693" type="cve"></reference>
          </references>
          <description>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-3019)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-2023-6683)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-6693)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-89.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-89.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="89.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-89.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1317</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36764" id="CVE-2022-36764" title="CVE-2022-36764" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45230" id="CVE-2023-45230" title="CVE-2023-45230" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45232" id="CVE-2023-45232" title="CVE-2023-45232" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45233" id="CVE-2023-45233" title="CVE-2023-45233" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45235" id="CVE-2023-45235" title="CVE-2023-45235" type="cve"></reference>
          </references>
          <description>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-36764) EDK2&#39;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-45230) EDK2&#39;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-45232) EDK2&#39;s Network Package is susceptible to an infinite lop vulnerability when parsing a PadN option in the Destination Options header of IPv6. This vulnerability can be exploited by an attacker to gain unauthorized access and potentially lead to a loss of Availability.(CVE-2023-45233) EDK2&#39;s Network Package is susceptible to a buffer overflow vulnerability whenhandling 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-45235)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debuginfo" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="16.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="16.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="16.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1320</id>
          <title>An update for python-aiosmtpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-03-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27305" id="CVE-2024-27305" title="CVE-2024-27305" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-27305)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-aiosmtpd" release="2.oe2203sp1" version="1.4.2">
                         <filename>python3-aiosmtpd-1.4.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-aiosmtpd-help" release="2.oe2203sp1" version="1.4.2">
                         <filename>python-aiosmtpd-help-1.4.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1324</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-22"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4408" id="CVE-2023-4408" title="CVE-2023-4408" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50387" id="CVE-2023-50387" title="CVE-2023-50387" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5517" id="CVE-2023-5517" title="CVE-2023-5517" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5679" id="CVE-2023-5679" title="CVE-2023-5679" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6516" id="CVE-2023-6516" title="CVE-2023-6516" type="cve"></reference>
          </references>
          <description>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-4408)Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the &#34;KeyTrap&#34; issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.(CVE-2023-50387)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-5517)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-5679)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.(CVE-2023-6516)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="21.oe2203sp1" version="9.16.23">
                         <filename>python3-bind-9.16.23-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-license-9.16.23-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="21.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1329</id>
          <title>An update for python-yaql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29156" id="CVE-2024-29156" title="CVE-2024-29156" type="cve"></reference>
          </references>
          <description>In OpenStack Murano through 16.0.0, when YAQL before 3.0.0 is used, the Murano service&#39;s MuranoPL extension to the YAQL language fails to sanitize the supplied environment, leading to potential leakage of sensitive service account information.(CVE-2024-29156)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-yaql-help" release="2.oe2203sp1" version="2.0.0">
                         <filename>python-yaql-help-2.0.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-yaql" release="2.oe2203sp1" version="2.0.0">
                         <filename>python3-yaql-2.0.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1348</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47014" id="CVE-2021-47014" title="CVE-2021-47014" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47036" id="CVE-2021-47036" title="CVE-2021-47036" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52445" id="CVE-2023-52445" title="CVE-2023-52445" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52458" id="CVE-2023-52458" title="CVE-2023-52458" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52528" id="CVE-2023-52528" title="CVE-2023-52528" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52593" id="CVE-2023-52593" title="CVE-2023-52593" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52602" id="CVE-2023-52602" title="CVE-2023-52602" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52603" id="CVE-2023-52603" title="CVE-2023-52603" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52604" id="CVE-2023-52604" title="CVE-2023-52604" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:net/sched: act_ct: fix wild memory access when clearing fragmentswhile testing re-assembly/re-fragmentation using act_ct, it&#39;s possible toobserve 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 cbresults in putting random data in FRAG_CB(), and this causes those &#34;wild&#34;memory accesses later, when the rbtree is purged. Never overwrite the skbcb in case tcf_ct_handle_fragments() returns -EINPROGRESS.(CVE-2021-47014)In the Linux kernel, the following vulnerability has been resolved:udp: skip L4 aggregation for UDP tunnel packetsIf NETIF_F_GRO_FRAGLIST or NETIF_F_GRO_UDP_FWD are enabled, and thereare UDP tunnels available in the system, udp_gro_receive() could end-updoing L4 aggregation (either SKB_GSO_UDP_L4 or SKB_GSO_FRAGLIST) atthe outer UDP tunnel level for packets effectively carrying and UDPtunnel header.That could cause inner protocol corruption. If e.g. the relevantpackets 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 GROengine till the next flush, etc.Just skip the SKB_GSO_UDP_L4 and SKB_GSO_FRAGLIST code path if thecurrent 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 strictlyneeded, as the existing UDP tunnel could be e.g. configured on top ofa 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 quitea bit of complexity.v1 -&gt; v2: - hopefully clarify the commit message(CVE-2021-47036)In the Linux kernel, the following vulnerability has been resolved:media: pvrusb2: fix use after free on context disconnectionUpon module load, a kthread is created targeting thepvr2_context_thread_func function, which may call pvr2_context_destroyand thus call kfree() on the context object. However, that might happenbefore the usb hub_event handler is able to notify the driver. Thispatch adds a sanity check before the invalid read reported by syzbot,within the context disconnection call stack.(CVE-2023-52445)In the Linux kernel, the following vulnerability has been resolved:block: add check that partition length needs to be aligned with block sizeBefore calling add partition or resize partition, there is no checkon 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 thanthe logical block size.If integrity data is supported, this will alsoresult in a null pointer dereference when calling bio_integrity_free.(CVE-2023-52458)In the Linux kernel, the following vulnerability has been resolved:net: usb: smsc75xx: Fix uninit-value access in __smsc75xx_read_regsyzbot 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:1482CPU: 0 PID: 8696 Comm: kworker/0:3 Not tainted 5.8.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: usb_hub_wq hub_eventCall 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:293Local 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:1482This issue is caused because usbnet_read_cmd() reads less bytes than requested(zero byte in the reproducer). In this case, &#39;buf&#39; is not properly filled.This patch fixes the issue by returning -ENODATA if usbnet_read_cmd() readsless bytes than requested.(CVE-2023-52528)In the Linux kernel, the following vulnerability has been resolved:wifi: wfx: fix possible NULL pointer dereference in wfx_set_mfp_ap()Since &#39;ieee80211_beacon_get()&#39; can return NULL, &#39;wfx_set_mfp_ap()&#39;should check the return value before examining skb data. So convertthe latter to return an appropriate error code and propagate it toreturn from &#39;wfx_start_ap()&#39; as well. Compile tested only.(CVE-2023-52593)In the Linux kernel, the following vulnerability has been resolved:jfs: fix slab-out-of-bounds Read in dtSearchCurrently while searching for current page in the sorted entry tableof the page there is a out of bound access. Added a bound check to fixthe error.Dave:Set return code to -EIO(CVE-2023-52602)In the Linux kernel, the following vulnerability has been resolved:UBSAN: array-index-out-of-bounds in dtSplitRootSyzkaller reported the following issue:oop0: detected capacity change from 0 to 32768UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dtree.c:1971:9index -2 is out of range for type &#39;struct dtslot [128]&#39;CPU: 0 PID: 3613 Comm: syz-executor270 Not tainted 6.0.0-syzkaller-09423-g493ffd6605b2 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/22/2022Call 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/0xcdRIP: 0033:0x7fcdc0113fd9Code: 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 48RSP: 002b:00007ffeb8bc67d8 EFLAGS: 00000246 ORIG_RAX: 0000000000000102RAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007fcdc0113fd9RDX: 0000000000000000 RSI: 0000000020000340 RDI: 0000000000000003RBP: 00007fcdc00d37a0 R08: 0000000000000000 R09: 00007fcdc00d37a0R10: 00005555559a72c0 R11: 0000000000000246 R12: 00000000f8008000R13: 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 presentbut 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-52603)In the Linux kernel, the following vulnerability has been resolved:FS:JFS:UBSAN:array-index-out-of-bounds in dbAdjTreeSyzkaller reported the following issue:UBSAN: array-index-out-of-bounds in fs/jfs/jfs_dmap.c:2867:6index 196694 is out of range for type &#39;s8[1365]&#39; (aka &#39;signed char[1365]&#39;)CPU: 1 PID: 109 Comm: jfsCommit Not tainted 6.6.0-rc3-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023Call 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 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/04/2023Call 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: disabledRebooting in 86400 seconds..The issue is caused when the value of lp becomes greater thanCTLTREESIZE which is the max size of stree. Adding a simple checksolves this issue.Dave:As the function returns a void, good error handlingwould require a more intrusive code reorganization, so I modifiedOsama&#39;s patch at use WARN_ON_ONCE for lack of a cleaner option.The patch is tested via syzbot.(CVE-2023-52604)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.69.0.149.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-devel" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.69.0.149.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.69.0.149.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1350</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-03-29"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36765" id="CVE-2022-36765" title="CVE-2022-36765" type="cve"></reference>
          </references>
          <description>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-2022-36765)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debugsource" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debuginfo" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="16.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="16.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="16.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="16.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="16.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1352</id>
          <title>An update for util-linux is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-04-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28085" id="CVE-2024-28085" title="CVE-2024-28085" type="cve"></reference>
          </references>
          <description>wall in util-linux through 2.40, often installed with setgid tty permissions, allows escape sequences to be sent to other users&#39; terminals through argv. (Specifically, escape sequences received from stdin are blocked, but escape sequences received from argv are not blocked.) There may be plausible scenarios where this leads to account takeover.(CVE-2024-28085)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="util-linux-debugsource" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-debugsource-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libsmartcols" release="28.oe2203sp1" version="2.37.2">
                         <filename>libsmartcols-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libmount" release="28.oe2203sp1" version="2.37.2">
                         <filename>libmount-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libuuid" release="28.oe2203sp1" version="2.37.2">
                         <filename>libuuid-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-libmount" release="28.oe2203sp1" version="2.37.2">
                         <filename>python3-libmount-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libfdisk" release="28.oe2203sp1" version="2.37.2">
                         <filename>libfdisk-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uuidd" release="28.oe2203sp1" version="2.37.2">
                         <filename>uuidd-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="util-linux-devel" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-devel-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="util-linux-debuginfo" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-debuginfo-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="util-linux-user" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-user-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="util-linux" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libblkid" release="28.oe2203sp1" version="2.37.2">
                         <filename>libblkid-2.37.2-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="util-linux-help" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-help-2.37.2-28.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libmount" release="28.oe2203sp1" version="2.37.2">
                         <filename>python3-libmount-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libmount" release="28.oe2203sp1" version="2.37.2">
                         <filename>libmount-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libblkid" release="28.oe2203sp1" version="2.37.2">
                         <filename>libblkid-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="util-linux-user" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-user-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="util-linux-debuginfo" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-debuginfo-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libuuid" release="28.oe2203sp1" version="2.37.2">
                         <filename>libuuid-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="util-linux-debugsource" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-debugsource-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libfdisk" release="28.oe2203sp1" version="2.37.2">
                         <filename>libfdisk-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="util-linux-devel" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-devel-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libsmartcols" release="28.oe2203sp1" version="2.37.2">
                         <filename>libsmartcols-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="util-linux" release="28.oe2203sp1" version="2.37.2">
                         <filename>util-linux-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uuidd" release="28.oe2203sp1" version="2.37.2">
                         <filename>uuidd-2.37.2-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1354</id>
          <title>An update for telnet is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39028" id="CVE-2022-39028" title="CVE-2022-39028" type="cve"></reference>
          </references>
          <description>telnetd in GNU Inetutils through 2.3, MIT krb5-appl through 1.0.3, and derivative works has a NULL pointer dereference via 0xff 0xf7 or 0xff 0xf8. In a typical installation, the telnetd application would crash but the telnet service would remain available through inetd. However, if the telnetd application has many crashes within a short time interval, the telnet service would become unavailable after inetd logs a &#34;telnet/tcp server failing (looping), service terminated&#34; error. NOTE: MIT krb5-appl is not supported upstream but is shipped by a few Linux distributions. The affected code was removed from the supported MIT Kerberos 5 (aka krb5) product many years ago, at version 1.8.(CVE-2022-39028)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="telnet-debugsource" release="79.oe2203sp1" version="0.17">
                         <filename>telnet-debugsource-0.17-79.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="telnet-help" release="79.oe2203sp1" version="0.17">
                         <filename>telnet-help-0.17-79.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="telnet" release="79.oe2203sp1" version="0.17">
                         <filename>telnet-0.17-79.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="telnet-debuginfo" release="79.oe2203sp1" version="0.17">
                         <filename>telnet-debuginfo-0.17-79.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="telnet" release="79.oe2203sp1" version="0.17">
                         <filename>telnet-0.17-79.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="telnet-debugsource" release="79.oe2203sp1" version="0.17">
                         <filename>telnet-debugsource-0.17-79.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="telnet-debuginfo" release="79.oe2203sp1" version="0.17">
                         <filename>telnet-debuginfo-0.17-79.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="telnet-help" release="79.oe2203sp1" version="0.17">
                         <filename>telnet-help-0.17-79.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1357</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-03"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47094" id="CVE-2021-47094" title="CVE-2021-47094" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52502" id="CVE-2023-52502" title="CVE-2023-52502" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52599" id="CVE-2023-52599" title="CVE-2023-52599" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52600" id="CVE-2023-52600" title="CVE-2023-52600" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52601" id="CVE-2023-52601" title="CVE-2023-52601" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23307" id="CVE-2024-23307" title="CVE-2024-23307" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26622" id="CVE-2024-26622" title="CVE-2024-26622" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26625" id="CVE-2024-26625" title="CVE-2024-26625" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26627" id="CVE-2024-26627" title="CVE-2024-26627" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:KVM: x86/mmu: Don&#39;t advance iterator after restart due to yieldingAfter dropping mmu_lock in the TDP MMU, restart the iterator duringtdp_iter_next() and do not advance the iterator.  Advancing the iteratorresults in skipping the top-level SPTE and all its children, which isfatal if any of the skipped SPTEs were not visited before yielding.When zapping all SPTEs, i.e. when min_level == root_level, restarting theiter and then invoking tdp_iter_next() is always fatal if the current gfnhas as a valid SPTE, as advancing the iterator results in try_step_side()skipping the current gfn, which wasn&#39;t visited before yielding.Sprinkle WARNs on iter-&gt;yielded being true in various helpers that areoften 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 validSPTE 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/0xaeIf kvm_tdp_mmu_zap_all() skips a gfn/SPTE but that SPTE is then zapped bykvm_tdp_mmu_put_root(), KVM triggers a use-after-free in the form ofmarking a struct page as dirty/accessed after it has been put back on thefree list.  This directly triggers a WARN due to encountering a page withpage_count() == 0, but it can also lead to data corruption and additionalerrors 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/0xaeNote, the underlying bug existed even before commit 1af4a96025b3 (&#34;KVM:x86/mmu: Yield in TDU MMU iter even if no SPTES changed&#34;) moved calls totdp_mmu_iter_cond_resched() to the beginning of loops, as KVM could stillincorrectly advance past a top-level entry when yielding on a lower-levelentry.  But with respect to leaking shadow pages, the bug was introducedby yielding before processing the current gfn.Alternatively, tdp_mmu_iter_cond_resched() could simply fall through, orcallers could jump to their &#34;retry&#34; label.  The downside of that approachis that tdp_mmu_iter_cond_resched() _must_ be called before anything elsein the loop, and there&#39;s no easy way to enfornce that requirement.Ideally, KVM would handling the cond_resched() fully within the iteratormacro (the code is actually quite clean) and avoid this entire class ofbugs, but that is extremely difficult do wh---truncated---(CVE-2021-47094)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 whileholding 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 socketfound by nfc_llcp_sock_from_sn() does not disappear.(CVE-2023-52502)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:2index -878706688 is out of range for type &#39;struct iagctl[128]&#39;CPU: 1 PID: 5065 Comm: syz-executor282 Not tainted 6.7.0-rc4-syzkaller-00009-gbee0e7762ad2 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/10/2023Call 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/0x6bRIP: 0033:0x7fcb7e6a0b57Code: 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 48RSP: 002b:00007ffd83023038 EFLAGS: 00000286 ORIG_RAX: 0000000000000053RAX: ffffffffffffffda RBX: 00000000ffffffff RCX: 00007fcb7e6a0b57RDX: 00000000000a1020 RSI: 00000000000001ff RDI: 0000000020000140RBP: 0000000020000140 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000286 R12: 00007ffd830230d0R13: 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-nextreport by kernel test robot (Dan Carpenter).(CVE-2023-52599)In the Linux kernel, the following vulnerability has been resolved:jfs: fix uaf in jfs_evict_inodeWhen the execution of diMount(ipimap) fails, the object ipimap that has beenreleased may be accessed in diFreeSpecial(). Asynchronous ipimap release occurswhen rcu_core() calls jfs_free_node().Therefore, when diMount(ipimap) fails, sbi-&gt;ipimap should not be initialized asipimap.(CVE-2023-52600)In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in dbAdjTreeCurrently there is a bound check missing in the dbAdjTree whileaccessing the dmt_stree. To add the required check added the bool is_ctlwhich is required to determine the size as suggest in the followingcommit.https://lore.kernel.org/linux-kernel-mentees/f9475918-2186-49b8-b801-6f0f9e75f4fa@oracle.com/(CVE-2023-52601)Integer Overflow or Wraparound vulnerability in Linux Linux kernel kernel on Linux, x86, ARM (md, raid, raid5 modules) allows Forced Integer Overflow.(CVE-2024-23307)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 afterhead-&gt;io_sem is held.  Otherwise, concurrent write() requests cancause use-after-free-write and double-free problems.(CVE-2024-26622)In the Linux kernel, the following vulnerability has been resolved:llc: call sock_orphan() at release timesyzbot reported an interesting trace [1] caused by a stale sk-&gt;sk_wqpointer in a closed llc socket.In commit ff7b11aa481f (&#34;net: socket: set sock-&gt;sk to NULL aftercalling proto_ops::release()&#34;) Eric Biggers hinted that some protocolsare missing a sock_orphan(), we need to perform a full audit.In net-next, I plan to clear sock-&gt;sk from sock_orphan() andamend 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:2468Read of size 8 at addr ffff88802f4fc880 by task ksoftirqd/1/27CPU: 1 PID: 27 Comm: ksoftirqd/1 Not tainted 6.8.0-rc1-syzkaller-00049-g6098d87eaf31 #0Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014Call 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/0x6bFreed 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-2024-26625)In the Linux kernel, the following vulnerability has been resolved:scsi: core: Move scsi_host_busy() out of host lock for waking up EH handlerInside scsi_eh_wakeup(), scsi_host_busy() is called &amp; checked with hostlock 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/requestsIf recovery is triggered in case that all requests are in-flight, eachscsi_eh_wakeup() is strictly serialized, when scsi_eh_wakeup() is calledfor 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 acquiringhost 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&#39;tneed the host lock for getting busy count because host the lock nevercovers that.[mkp: Drop unnecessary &#39;busy&#39; variables pointed out by Bart](CVE-2024-26627)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.70.0.150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.70.0.150.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.70.0.150.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1365</id>
          <title>An update for rubygem-activestorage is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26144" id="CVE-2024-26144" title="CVE-2024-26144" type="cve"></reference>
          </references>
          <description>Rails is a web-application framework. Starting with version 5.2.0, there is a possible sensitive session information leak in Active Storage. By default, Active Storage sends a Set-Cookie header along with the user&#39;s session cookie when serving blobs. It also sets Cache-Control to public. Certain proxies may cache the Set-Cookie, leading to an information leak. The vulnerability is fixed in 7.0.8.1 and 6.1.7.7.(CVE-2024-26144)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rubygem-activestorage" release="2.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activestorage-6.1.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-activestorage-doc" release="2.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activestorage-doc-6.1.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1372</id>
          <title>An update for unixODBC is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1013" id="CVE-2024-1013" title="CVE-2024-1013" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-1013)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="unixODBC" release="3.h1.oe2203sp1" version="2.3.7">
                         <filename>unixODBC-2.3.7-3.h1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unixODBC-debugsource" release="3.h1.oe2203sp1" version="2.3.7">
                         <filename>unixODBC-debugsource-2.3.7-3.h1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unixODBC-devel" release="3.h1.oe2203sp1" version="2.3.7">
                         <filename>unixODBC-devel-2.3.7-3.h1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unixODBC-debuginfo" release="3.h1.oe2203sp1" version="2.3.7">
                         <filename>unixODBC-debuginfo-2.3.7-3.h1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unixODBC-devel" release="3.h1.oe2203sp1" version="2.3.7">
                         <filename>unixODBC-devel-2.3.7-3.h1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unixODBC-debuginfo" release="3.h1.oe2203sp1" version="2.3.7">
                         <filename>unixODBC-debuginfo-2.3.7-3.h1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unixODBC-debugsource" release="3.h1.oe2203sp1" version="2.3.7">
                         <filename>unixODBC-debugsource-2.3.7-3.h1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unixODBC" release="3.h1.oe2203sp1" version="2.3.7">
                         <filename>unixODBC-2.3.7-3.h1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1378</id>
          <title>An update for mod_security is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48279" id="CVE-2022-48279" title="CVE-2022-48279" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-48279)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mod_security-debugsource" release="9.oe2203sp1" version="2.9.5">
                         <filename>mod_security-debugsource-2.9.5-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_security" release="9.oe2203sp1" version="2.9.5">
                         <filename>mod_security-2.9.5-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_security-debuginfo" release="9.oe2203sp1" version="2.9.5">
                         <filename>mod_security-debuginfo-2.9.5-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_security-debuginfo" release="9.oe2203sp1" version="2.9.5">
                         <filename>mod_security-debuginfo-2.9.5-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_security-debugsource" release="9.oe2203sp1" version="2.9.5">
                         <filename>mod_security-debugsource-2.9.5-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_security" release="9.oe2203sp1" version="2.9.5">
                         <filename>mod_security-2.9.5-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1379</id>
          <title>An update for expat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52426" id="CVE-2023-52426" title="CVE-2023-52426" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28757" id="CVE-2024-28757" title="CVE-2024-28757" type="cve"></reference>
          </references>
          <description>libexpat through 2.5.0 allows recursive XML Entity Expansion if XML_DTD is undefined at compile time.(CVE-2023-52426)libexpat through 2.6.1 allows an XML Entity Expansion attack when there is isolated use of external parsers (created via XML_ExternalEntityParserCreate).(CVE-2024-28757)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="expat-devel" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-devel-2.4.1-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-2.4.1-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debuginfo" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debugsource" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="expat-help" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-help-2.4.1-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debuginfo" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debugsource" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-devel" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-devel-2.4.1-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat" release="10.oe2203sp1" version="2.4.1">
                         <filename>expat-2.4.1-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1380</id>
          <title>An update for cri-tools is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24786" id="CVE-2024-24786" title="CVE-2024-24786" type="cve"></reference>
          </references>
          <description>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-41723)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.(CVE-2023-39325)The protojson.Unmarshal function can enter an infinite loop when unmarshaling certain forms of invalid JSON. This condition can occur when unmarshaling into a message which contains a google.protobuf.Any value, or when the UnmarshalOptions.DiscardUnknown option is set.(CVE-2024-24786)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cri-tools-debuginfo" release="5.oe2203sp1" version="1.22.0">
                         <filename>cri-tools-debuginfo-1.22.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cri-tools-debugsource" release="5.oe2203sp1" version="1.22.0">
                         <filename>cri-tools-debugsource-1.22.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cri-tools" release="5.oe2203sp1" version="1.22.0">
                         <filename>cri-tools-1.22.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-tools-debuginfo" release="5.oe2203sp1" version="1.22.0">
                         <filename>cri-tools-debuginfo-1.22.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-tools-debugsource" release="5.oe2203sp1" version="1.22.0">
                         <filename>cri-tools-debugsource-1.22.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-tools" release="5.oe2203sp1" version="1.22.0">
                         <filename>cri-tools-1.22.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1384</id>
          <title>An update for openvswitch is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2639" id="CVE-2022-2639" title="CVE-2022-2639" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-2639)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openvswitch" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-help" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-debuginfo" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-debugsource" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvswitch-devel" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debuginfo" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debuginfo-2.12.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-2.12.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-help" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-help-2.12.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-devel" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-devel-2.12.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvswitch-debugsource" release="8.oe2203sp1" version="2.12.4">
                         <filename>openvswitch-debugsource-2.12.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1386</id>
          <title>An update for ignition is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-39325)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ignition" release="4.oe2203sp1" version="2.14.0">
                         <filename>ignition-2.14.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition-debuginfo" release="4.oe2203sp1" version="2.14.0">
                         <filename>ignition-debuginfo-2.14.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition-debugsource" release="4.oe2203sp1" version="2.14.0">
                         <filename>ignition-debugsource-2.14.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition-validate" release="4.oe2203sp1" version="2.14.0">
                         <filename>ignition-validate-2.14.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-debuginfo" release="4.oe2203sp1" version="2.14.0">
                         <filename>ignition-debuginfo-2.14.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-debugsource" release="4.oe2203sp1" version="2.14.0">
                         <filename>ignition-debugsource-2.14.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-validate" release="4.oe2203sp1" version="2.14.0">
                         <filename>ignition-validate-2.14.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition" release="4.oe2203sp1" version="2.14.0">
                         <filename>ignition-2.14.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1388</id>
          <title>An update for python-pymongo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21506" id="CVE-2024-21506" title="CVE-2024-21506" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-21506)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python-pymongo-debugsource" release="3.oe2203sp1" version="3.11.3">
                         <filename>python-pymongo-debugsource-3.11.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pymongo" release="3.oe2203sp1" version="3.11.3">
                         <filename>python3-pymongo-3.11.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pymongo-debuginfo" release="3.oe2203sp1" version="3.11.3">
                         <filename>python-pymongo-debuginfo-3.11.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pymongo-gridfs" release="3.oe2203sp1" version="3.11.3">
                         <filename>python3-pymongo-gridfs-3.11.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-bson" release="3.oe2203sp1" version="3.11.3">
                         <filename>python3-bson-3.11.3-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-pymongo-help" release="3.oe2203sp1" version="3.11.3">
                         <filename>python-pymongo-help-3.11.3-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pymongo-gridfs" release="3.oe2203sp1" version="3.11.3">
                         <filename>python3-pymongo-gridfs-3.11.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pymongo-debugsource" release="3.oe2203sp1" version="3.11.3">
                         <filename>python-pymongo-debugsource-3.11.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pymongo" release="3.oe2203sp1" version="3.11.3">
                         <filename>python3-pymongo-3.11.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pymongo-debuginfo" release="3.oe2203sp1" version="3.11.3">
                         <filename>python-pymongo-debuginfo-3.11.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-bson" release="3.oe2203sp1" version="3.11.3">
                         <filename>python3-bson-3.11.3-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1389</id>
          <title>An update for nghttp2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28182" id="CVE-2024-28182" title="CVE-2024-28182" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-28182)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nghttp2-debuginfo" release="6.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debuginfo-1.46.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnghttp2-devel" release="6.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-devel-1.46.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnghttp2" release="6.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-1.46.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nghttp2-debugsource" release="6.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debugsource-1.46.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nghttp2" release="6.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-1.46.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="nghttp2-help" release="6.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-help-1.46.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2-debuginfo" release="6.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debuginfo-1.46.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2" release="6.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-1.46.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnghttp2" release="6.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-1.46.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nghttp2-debugsource" release="6.oe2203sp1" version="1.46.0">
                         <filename>nghttp2-debugsource-1.46.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnghttp2-devel" release="6.oe2203sp1" version="1.46.0">
                         <filename>libnghttp2-devel-1.46.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1390</id>
          <title>An update for emacs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30204" id="CVE-2024-30204" title="CVE-2024-30204" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30205" id="CVE-2024-30205" title="CVE-2024-30205" type="cve"></reference>
          </references>
          <description>In Emacs before 29.3, LaTeX preview is enabled by default for e-mail attachments.(CVE-2024-30204)In Emacs before 29.3, Org mode considers contents of remote files to be trusted. This affects Org Mode before 9.6.23.(CVE-2024-30205)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="emacs-devel" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-devel-27.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-27.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debugsource" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-debugsource-27.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-lucid" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-lucid-27.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-common" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-common-27.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-debuginfo" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-debuginfo-27.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="emacs-nox" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-nox-27.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-filesystem" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-filesystem-27.2-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-help" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-help-27.2-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="emacs-terminal" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-terminal-27.2-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-common" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-common-27.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-27.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-lucid" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-lucid-27.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-devel" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-devel-27.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-nox" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-nox-27.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debugsource" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-debugsource-27.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="emacs-debuginfo" release="13.oe2203sp1" version="27.2">
                         <filename>emacs-debuginfo-27.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1391</id>
          <title>An update for libvirt is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1441" id="CVE-2024-1441" title="CVE-2024-1441" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2494" id="CVE-2024-2494" title="CVE-2024-2494" type="cve"></reference>
          </references>
          <description>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-1441)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-2494)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libvirt-debuginfo" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debuginfo-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-config-network" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-network-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-libs" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-libs-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-devel" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-devel-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-qemu" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-qemu-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-lock-sanlock" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-lock-sanlock-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-logical" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-logical-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-wireshark" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-wireshark-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-iscsi" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-core" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-core-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-mpath" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-mpath-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-interface" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-interface-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-scsi" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-scsi-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-qemu" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-qemu-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-config-nwfilter" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-nwfilter-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-iscsi-direct" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-rbd" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-rbd-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-bash-completion" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-bash-completion-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-disk" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-disk-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-network" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-network-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-secret" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-secret-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-client" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-client-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-admin" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-admin-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-nodedev" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nodedev-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-nss" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-nss-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-kvm" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-kvm-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-gluster" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-gluster-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-docs" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-docs-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-debugsource" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debugsource-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-nwfilter" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nwfilter-6.2.0-63.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-gluster" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-gluster-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-devel" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-devel-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-network" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-network-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-disk" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-disk-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-core" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-core-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-debugsource" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debugsource-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-mpath" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-mpath-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-rbd" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-rbd-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-iscsi" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-docs" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-docs-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-nodedev" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nodedev-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-libs" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-libs-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-nwfilter" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nwfilter-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-iscsi-direct" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-debuginfo" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debuginfo-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-scsi" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-scsi-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-qemu" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-qemu-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-lock-sanlock" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-lock-sanlock-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-secret" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-secret-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-kvm" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-kvm-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-client" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-client-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-admin" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-admin-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-logical" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-logical-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-wireshark" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-wireshark-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-config-nwfilter" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-nwfilter-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-interface" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-interface-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-config-network" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-network-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-qemu" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-qemu-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-bash-completion" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-bash-completion-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-nss" release="63.oe2203sp1" version="6.2.0">
                         <filename>libvirt-nss-6.2.0-63.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1395</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46926" id="CVE-2021-46926" title="CVE-2021-46926" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47037" id="CVE-2021-47037" title="CVE-2021-47037" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52443" id="CVE-2023-52443" title="CVE-2023-52443" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52454" id="CVE-2023-52454" title="CVE-2023-52454" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52456" id="CVE-2023-52456" title="CVE-2023-52456" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52467" id="CVE-2023-52467" title="CVE-2023-52467" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52469" id="CVE-2023-52469" title="CVE-2023-52469" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52476" id="CVE-2023-52476" title="CVE-2023-52476" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52479" id="CVE-2023-52479" title="CVE-2023-52479" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52484" id="CVE-2023-52484" title="CVE-2023-52484" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26585" id="CVE-2024-26585" title="CVE-2024-26585" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26589" id="CVE-2024-26589" title="CVE-2024-26589" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26593" id="CVE-2024-26593" title="CVE-2024-26593" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26597" id="CVE-2024-26597" title="CVE-2024-26597" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26600" id="CVE-2024-26600" title="CVE-2024-26600" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26603" id="CVE-2024-26603" title="CVE-2024-26603" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26606" id="CVE-2024-26606" title="CVE-2024-26606" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: intel-sdw-acpi: harden detection of controllerThe existing code currently sets a pointer to an ACPI handle beforechecking that it&#39;s actually a SoundWire controller. This can lead toissues where the graph walk continues and eventually fails, but thepointer was set already.This patch changes the logic so that the information provided tothe caller is set when a controller is found.(CVE-2021-46926)In the Linux kernel, the following vulnerability has been resolved:ASoC: q6afe-clocks: fix reprobing of the driverQ6afe-clocks driver can get reprobed. For example if the APR servicesare restarted after the firmware crash. However currently Q6afe-clocksdriver will oops because hw.init will get cleared during first _probecall. Rewrite the driver to fill the clock data at runtime rather thanusing big static array of clocks.(CVE-2021-47037)In the Linux kernel, the following vulnerability has been resolved:apparmor: avoid crash when parsed profile name is emptyWhen processing a packed profile in unpack_profile() described like &#34;profile :ns::samba-dcerpcd /usr/lib*/samba/{,samba/}samba-dcerpcd {...}&#34;a string &#34;:samba-dcerpcd&#34; is unpacked as a fully-qualified name and thenpassed to aa_splitn_fqname().aa_splitn_fqname() treats &#34;:samba-dcerpcd&#34; as only containing a namespace.Thus it returns NULL for tmpname, meanwhile tmpns is non-NULL. Lateraa_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 NOPTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 6 PID: 1657 Comm: apparmor_parser Not tainted 6.7.0-rc2-dirty #16Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.2-3-gd478f380-rebuilt.opensuse.org 04/01/2014RIP: 0010:strlen+0x1e/0xa0Call 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/0xa0It seems such behaviour of aa_splitn_fqname() is expected and checked inother places where it is called (e.g. aa_remove_profiles). Well, thereis an explicit comment &#34;a ns name without a following profile is allowed&#34;inside.AFAICS, nothing can prevent unpacked &#34;name&#34; to be in form like&#34;:samba-dcerpcd&#34; - it is passed from userspace.Deny the whole profile set replacement in such case and inform user withEPROTO and an explaining message.Found by Linux Verification Center (linuxtesting.org).(CVE-2023-52443)In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: Fix a kernel panic when host sends an invalid H2C PDU lengthIf 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 atvirtual address 0000000000000000lr : nvmet_tcp_io_work+0x6ac/0x718 [nvmet_tcp]Call trace:  process_one_work+0x174/0x3c8  worker_thread+0x2d0/0x3e8  kthread+0x104/0x110Fix the bug by raising a fatal error if DATAL isn&#39;t coherentwith the packet size.Also, the PDU length should never exceed the MAXH2CDATA parameter whichhas been communicated to the host in nvmet_tcp_handle_icreq().(CVE-2023-52454)In the Linux kernel, the following vulnerability has been resolved:serial: imx: fix tx statemachine deadlockWhen using the serial port as RS485 port, the tx statemachine is used tocontrol the RTS pin to drive the RS485 transceiver TX_EN pin. When theTTY port is closed in the middle of a transmission (for instance duringuserland application crash), imx_uart_shutdown disables the interfaceand disables the Transmission Complete interrupt. afer that,imx_uart_stop_tx bails on an incomplete transmission, to be retriggeredby the TC interrupt. This interrupt is disabled and therefore the txstatemachine never transitions out of SEND. The statemachine is indeadlock now, and the TX_EN remains low, making the interface useless.imx_uart_stop_tx now checks for incomplete transmission AND whether TCinterrupts are enabled before bailing to be retriggered. This makes surethe state machine handling is reached, and is properly set toWAIT_AFTER_SEND.(CVE-2023-52456)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 memorywhich can be NULL upon failure.(CVE-2023-52467)In the Linux kernel, the following vulnerability has been resolved:drivers/amd/pm: fix a use-after-free in kv_parse_power_tableWhen ps allocated by kzalloc equals to NULL, kv_parse_power_tablefrees adev-&gt;pm.dpm.ps that allocated before. However, after the controlflow goes through the following call chains:kv_parse_power_table  |-&gt; kv_dpm_init        |-&gt; kv_dpm_sw_init&#x9;      |-&gt; kv_dpm_finiThe adev-&gt;pm.dpm.ps is used in the for loop of kv_dpm_fini after itsfirst free in kv_parse_power_table and causes a use-after-free bug.(CVE-2023-52469)In the Linux kernel, the following vulnerability has been resolved:perf/x86/lbr: Filter vsyscall addressesWe found that a panic can occur when a vsyscall is made while LBR samplingis active. If the vsyscall is interrupted (NMI) for perf sampling, thiscall 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_byteInspecting registers at this point, the value of the next_byte field is theaddress of the vsyscall made, for example the location of the vsyscallversion of gettimeofday() at 0xffffffffff600000. The access to an addressin the vsyscall region will trigger an oops due to an unhandled page fault.To fix the bug, filtering for vsyscalls can be done whendetermining the branch type. This patch will returna &#34;none&#34; branch if a kernel address if found to lie in thevsyscall region.(CVE-2023-52476)In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix uaf in smb20_oplock_break_ackdrop reference after use opinfo.(CVE-2023-52479)In the Linux kernel, the following vulnerability has been resolved:iommu/arm-smmu-v3: Fix soft lockup triggered by arm_smmu_mm_invalidate_rangeWhen 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/0xa50lr : arm_smmu_cmdq_issue_cmdlist+0x150/0xa50sp : ffff8000d83ef290x29: ffff8000d83ef290 x28: 000000003b9aca00 x27: 0000000000000000x26: ffff8000d83ef3c0 x25: da86c0812194a0e8 x24: 0000000000000000x23: 0000000000000040 x22: ffff8000d83ef340 x21: ffff0000c63980c0x20: 0000000000000001 x19: ffff0000c6398080 x18: 0000000000000000x17: 0000000000000000 x16: 0000000000000000 x15: ffff3000b4a3bbb0x14: ffff3000b4a30888 x13: ffff3000b4a3cf60 x12: 0000000000000000x11: 0000000000000000 x10: 0000000000000000 x9 : ffffc08120e4d6bcx8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000048cfax5 : 0000000000000000 x4 : 0000000000000001 x3 : 000000000000000ax2 : 0000000080000000 x1 : 0000000000000000 x0 : 0000000000000001Call 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 renamedto &#34;arm_smmu_mm_arch_invalidate_secondary_tlbs&#34;, yet the problem remains.The commit 06ff87bae8d3 (&#34;arm64: mm: remove unused functions and variableprotoypes&#34;) fixed a similar lockup on the CPU MMU side. Yet, it can occurto SMMU too, since arm_smmu_mm_arch_invalidate_secondary_tlbs() is calledtypically next to MMU tlb flush function, e.g.&#x9;tlb_flush_mmu_tlbonly {&#x9;&#x9;tlb_flush {&#x9;&#x9;&#x9;__flush_tlb_range {&#x9;&#x9;&#x9;&#x9;// check MAX_TLBI_OPS&#x9;&#x9;&#x9;}&#x9;&#x9;}&#x9;&#x9;mmu_notifier_arch_invalidate_secondary_tlbs {&#x9;&#x9;&#x9;arm_smmu_mm_arch_invalidate_secondary_tlbs {&#x9;&#x9;&#x9;&#x9;// does not check MAX_TLBI_OPS&#x9;&#x9;&#x9;}&#x9;&#x9;}&#x9;}Clone a CMDQ_MAX_TLBI_OPS from the MAX_TLBI_OPS in tlbflush.h, since in anSVA case SMMU uses the CPU page table, so it makes sense to align with thetlbflush code. Then, replace per-page TLBI commands with a single per-asidTLBI command, if the request size hits this threshold.(CVE-2023-52484)In the Linux kernel, the following vulnerability has been resolved:tls: fix race between tx work scheduling and socket closeSimilarly to previous commit, the submitting thread (recvmsg/sendmsg)may exit as soon as the async crypto handler calls complete().Reorder scheduling the work before calling complete().This seems more logical in the first place, as it&#39;sthe inverse order of what the submitting thread will do.(CVE-2024-26585)In the Linux kernel, the following vulnerability has been resolved:bpf: Reject variable offset alu on PTR_TO_FLOW_KEYSFor PTR_TO_FLOW_KEYS, check_flow_keys_access() only uses fixed offfor validation. However, variable offset ptr alu is not prohibitedfor 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) exitThis prog loads flow_keys to r7, and adds the variable offset r8to 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/0x6bFix this by rejecting ptr alu with variable offset on flow_keys.Applying the patch rejects the program with &#34;R7 pointer arithmeticon flow_keys prohibited&#34;.(CVE-2024-26589)In the Linux kernel, the following vulnerability has been resolved:i2c: i801: Fix block process call transactionsAccording to the Intel datasheets, software must reset the blockbuffer index twice for block process call transactions: once beforewriting the outgoing data to the buffer, and once again beforereading the incoming data from the buffer.The driver is currently missing the second reset, causing the wrongportion of the block buffer to be read.(CVE-2024-26593)In the Linux kernel, the following vulnerability has been resolved:net: qualcomm: rmnet: fix global oob in rmnet_policyThe variable rmnet_link_ops assign a *bigger* maxtype which leads to aglobal out-of-bounds read when parsing the netlink attributes. See bugtrace 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:600Read of size 1 at addr ffffffff92c438d0 by task syz-executor.6/84207CPU: 0 PID: 84207 Comm: syz-executor.6 Tainted: G                 N 6.1.0 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014Call 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/0xcdRIP: 0033:0x7fdcf2072359Code: 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 48RSP: 002b:00007fdcf13e3168 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007fdcf219ff80 RCX: 00007fdcf2072359RDX: 0000000000000000 RSI: 0000000020000200 RDI: 0000000000000003RBP: 00007fdcf20bd493 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007fffbb8d7bdf R14: 00007fdcf13e3300 R15: 0000000000022000 &lt;/TASK&gt;The buggy address belongs to the variable: rmnet_policy+0x30/0xe0The buggy address belongs to the physical page:page:0000000065bdeb3c refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x155243flags: 0x200000000001000(reserved|node=0|zone=2)raw: 0200000000001000 ffffea00055490c8 ffffea00055490c8 0000000000000000raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory 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 f9According to the comment of `nla_parse_nested_deprecated`, the maxtypeshould be len(destination array) - 1. Hence use `IFLA_RMNET_MAX` here.(CVE-2024-26597)In the Linux kernel, the following vulnerability has been resolved:phy: ti: phy-omap-usb2: Fix NULL pointer dereference for SRPIf the external phy working together with phy-omap-usb2 does not implementsend_srp(), we may still attempt to call it. This can happen on an idleEthernet gadget triggering a wakeup for example:configfs-gadget.g1 gadget.0: ECM Suspendconfigfs-gadget.g1 gadget.0: Port suspended. Triggering wakeup...Unable to handle kernel NULL pointer dereference at virtual address00000000 when execute...PC is at 0x0LR 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/0x24cdev_hard_start_xmit from sch_direct_xmit+0x104/0x2e4sch_direct_xmit from __dev_queue_xmit+0x334/0xd88__dev_queue_xmit from arp_solicit+0xf0/0x268arp_solicit from neigh_probe+0x54/0x7cneigh_probe from __neigh_event_send+0x22c/0x47c__neigh_event_send from neigh_resolve_output+0x14c/0x1c0neigh_resolve_output from ip_finish_output2+0x1c8/0x628ip_finish_output2 from ip_send_skb+0x40/0xd8ip_send_skb from udp_send_skb+0x124/0x340udp_send_skb from udp_sendmsg+0x780/0x984udp_sendmsg from __sys_sendto+0xd8/0x158__sys_sendto from ret_fast_syscall+0x0/0x58Let&#39;s fix the issue by checking for send_srp() and set_vbus() beforecalling them. For USB peripheral only cases these both could be NULL.(CVE-2024-26600)In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Stop relying on userspace for info to fault in xsave bufferBefore this change, the expected size of the user space buffer wastaken from fx_sw-&gt;xstate_size. fx_sw-&gt;xstate_size can be changedfrom 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 areawhich 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 andtries xrstor again. It will spin in this loop forever.Instead, fault in the maximum size which can be touched by XRSTOR (takenfrom fpstate-&gt;user_size).[ dhansen: tweak subject / changelog ](CVE-2024-26603)In the Linux kernel, the following vulnerability has been resolved:binder: signal epoll threads of self-workIn (e)poll mode, threads often depend on I/O events to determine whendata is ready for consumption. Within binder, a thread may initiate acommand via BINDER_WRITE_READ without a read buffer and then make useof epoll_wait() or similar to consume any responses afterwards.It is then crucial that epoll threads are signaled via wakeup when theyqueue their own work. Otherwise, they risk waiting indefinitely for anevent leaving their work unhandled. What is worse, subsequent commandswon&#39;t trigger a wakeup either as the thread has pending work.(CVE-2024-26606)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.71.0.151.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.71.0.151.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.71.0.151.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1403</id>
          <title>An update for nodejs-qs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24999" id="CVE-2022-24999" title="CVE-2022-24999" type="cve"></reference>
          </references>
          <description>qs before 6.10.3, as used in Express before 4.17.3 and other products, allows attackers to cause a Node process hang for an Express application because an __ proto__ key can be used. In many typical Express use cases, an unauthenticated remote attacker can place the attack payload in the query string of the URL that is used to visit the application, such as a[__proto__]=b&amp;a[__proto__]&amp;a[length]=100000000. The fix was backported to qs 6.9.7, 6.8.3, 6.7.3, 6.6.1, 6.5.3, 6.4.1, 6.3.3, and 6.2.4 (and therefore Express 4.17.3, which has &#34;deps: qs@6.9.7&#34; in its release description, is not vulnerable).(CVE-2022-24999)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="nodejs-qs" release="2.oe2203sp1" version="6.5.1">
                         <filename>nodejs-qs-6.5.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1405</id>
          <title>An update for mozjs78 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23599" id="CVE-2023-23599" title="CVE-2023-23599" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23601" id="CVE-2023-23601" title="CVE-2023-23601" type="cve"></reference>
          </references>
          <description>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-23599)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-23601)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mozjs91-devel" release="4.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-devel-91.6.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libmozjs-91-0" release="4.oe2203sp1" version="91.6.0">
                         <filename>libmozjs-91-0-91.6.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91" release="4.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-91.6.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-debugsource" release="4.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debugsource-91.6.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-debuginfo" release="4.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debuginfo-91.6.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-debuginfo" release="4.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debuginfo-91.6.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-debugsource" release="4.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debugsource-91.6.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-devel" release="4.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-devel-91.6.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libmozjs-91-0" release="4.oe2203sp1" version="91.6.0">
                         <filename>libmozjs-91-0-91.6.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91" release="4.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-91.6.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1406</id>
          <title>An update for cri-o is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-4318" id="CVE-2022-4318" title="CVE-2022-4318" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39325" id="CVE-2023-39325" title="CVE-2023-39325" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
          </references>
          <description>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-41723)A vulnerability was found in cri-o. This issue allows the addition of arbitrary lines into /etc/passwd by use of a specially crafted environment variable.(CVE-2022-4318)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.(CVE-2023-39325)The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.(CVE-2023-48795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cri-o-debuginfo" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debuginfo-1.23.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cri-o" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-1.23.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cri-o-debugsource" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debugsource-1.23.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o-debugsource" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debugsource-1.23.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-1.23.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o-debuginfo" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debuginfo-1.23.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1409</id>
          <title>An update for libreswan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2357" id="CVE-2024-2357" title="CVE-2024-2357" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-2357)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libreswan" release="1.oe2203sp1" version="4.14">
                         <filename>libreswan-4.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-help" release="1.oe2203sp1" version="4.14">
                         <filename>libreswan-help-4.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debugsource" release="1.oe2203sp1" version="4.14">
                         <filename>libreswan-debugsource-4.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debuginfo" release="1.oe2203sp1" version="4.14">
                         <filename>libreswan-debuginfo-4.14-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debuginfo" release="1.oe2203sp1" version="4.14">
                         <filename>libreswan-debuginfo-4.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan" release="1.oe2203sp1" version="4.14">
                         <filename>libreswan-4.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debugsource" release="1.oe2203sp1" version="4.14">
                         <filename>libreswan-debugsource-4.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-help" release="1.oe2203sp1" version="4.14">
                         <filename>libreswan-help-4.14-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1412</id>
          <title>An update for curl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2398" id="CVE-2024-2398" title="CVE-2024-2398" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-2398)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libcurl" release="28.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debuginfo" release="28.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl" release="28.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="curl-debugsource" release="28.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libcurl-devel" release="28.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="curl-help" release="28.oe2203sp1" version="7.79.1">
                         <filename>curl-help-7.79.1-28.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl" release="28.oe2203sp1" version="7.79.1">
                         <filename>libcurl-7.79.1-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libcurl-devel" release="28.oe2203sp1" version="7.79.1">
                         <filename>libcurl-devel-7.79.1-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl" release="28.oe2203sp1" version="7.79.1">
                         <filename>curl-7.79.1-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debugsource" release="28.oe2203sp1" version="7.79.1">
                         <filename>curl-debugsource-7.79.1-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="curl-debuginfo" release="28.oe2203sp1" version="7.79.1">
                         <filename>curl-debuginfo-7.79.1-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1415</id>
          <title>An update for varnish is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-30156" id="CVE-2024-30156" title="CVE-2024-30156" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-30156)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="varnish-debugsource" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-debugsource-7.4.3-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-devel" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-devel-7.4.3-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-7.4.3-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="varnish-debuginfo" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-debuginfo-7.4.3-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="varnish-help" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-help-7.4.3-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-devel" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-devel-7.4.3-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debugsource" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-debugsource-7.4.3-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-7.4.3-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="varnish-debuginfo" release="1.oe2203sp1" version="7.4.3">
                         <filename>varnish-debuginfo-7.4.3-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1416</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31080" id="CVE-2024-31080" title="CVE-2024-31080" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31081" id="CVE-2024-31081" title="CVE-2024-31081" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31082" id="CVE-2024-31082" title="CVE-2024-31082" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31083" id="CVE-2024-31083" title="CVE-2024-31083" type="cve"></reference>
          </references>
          <description>A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcXIGetSelectedEvents() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.(CVE-2024-31080)A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcXIPassiveGrabDevice() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.(CVE-2024-31081)A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcAppleDRICreatePixmap() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.(CVE-2024-31082)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-31083)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-common" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-29.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-29.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-29.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="29.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-29.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1418</id>
          <title>An update for iperf3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7250" id="CVE-2023-7250" title="CVE-2023-7250" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-7250)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iperf3-debuginfo" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-debuginfo-3.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-3.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-devel" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-devel-3.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-debugsource" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-debugsource-3.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="iperf3-help" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-help-3.16-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-3.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-devel" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-devel-3.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-debuginfo" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-debuginfo-3.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-debugsource" release="1.oe2203sp1" version="3.16">
                         <filename>iperf3-debugsource-3.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1420</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24474" id="CVE-2024-24474" title="CVE-2024-24474" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-24474)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-90.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-90.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="90.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-90.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1425</id>
          <title>An update for flatpak is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28100" id="CVE-2023-28100" title="CVE-2023-28100" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28101" id="CVE-2023-28101" title="CVE-2023-28101" type="cve"></reference>
          </references>
          <description>Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. Versions prior to 1.10.8, 1.12.8, 1.14.4, and 1.15.4 contain a vulnerability similar to CVE-2017-5226, but using the `TIOCLINUX` ioctl command instead of `TIOCSTI`. If a Flatpak app is run on a Linux virtual console such as `/dev/tty1`, it can copy text from the virtual console and paste it into the command buffer, from which the command might be run after the Flatpak app has exited. Ordinary graphical terminal emulators like xterm, gnome-terminal and Konsole are unaffected. This vulnerability is specific to the Linux virtual consoles `/dev/tty1`, `/dev/tty2` and so on. A patch is available in versions 1.10.8, 1.12.8, 1.14.4, and 1.15.4. As a workaround, don&#39;t run Flatpak on a Linux virtual console. Flatpak is primarily designed to be used in a Wayland or X11 graphical environment.(CVE-2023-28100)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.(CVE-2023-28101)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="flatpak-debugsource" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debugsource-1.10.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-1.10.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-devel" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-devel-1.10.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-debuginfo" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debuginfo-1.10.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="flatpak-help" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-help-1.10.2-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-debuginfo" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debuginfo-1.10.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-devel" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-devel-1.10.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-debugsource" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debugsource-1.10.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak" release="7.oe2203sp1" version="1.10.2">
                         <filename>flatpak-1.10.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1429</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0666" id="CVE-2023-0666" title="CVE-2023-0666" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-0666)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="7.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1432</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24784" id="CVE-2024-24784" title="CVE-2024-24784" type="cve"></reference>
          </references>
          <description>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-2024-24784)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="30.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="30.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-30.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="30.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-30.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="30.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1433</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27280" id="CVE-2024-27280" title="CVE-2024-27280" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27281" id="CVE-2024-27281" title="CVE-2024-27281" type="cve"></reference>
          </references>
          <description>A buffer overread flaw was found in rubygem StringIO. The ungetbyte and ungetc methods on a StringIO object can read past the end of a string, and a subsequent call to StringIO.gets may return the memory value.(CVE-2024-27280)A flaw was found in Rubygem RDoc. When parsing .rdoc_options used for configuration in RDoc as a YAML file there are no restrictions on the classes that can be restored. This issue may lead to object injection, resulting in remote code execution.(CVE-2024-27281)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby-devel" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="132.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="132.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="132.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="132.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="132.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-132.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="132.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="132.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="132.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="132.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="132.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="132.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="132.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="132.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="3" arch="noarch" name="ruby-help" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="132.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="132.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="132.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="132.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-132.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="132.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="132.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="132.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="132.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="132.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="132.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-132.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1437</id>
          <title>An update for pcp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3019" id="CVE-2024-3019" title="CVE-2024-3019" type="cve"></reference>
          </references>
          <description>A flaw was found in PCP. The default pmproxy configuration exposes the Redis server backend to the local network, allowing remote command execution with the privileges of the Redis user. This issue can only be exploited when pmproxy is running. By default, pmproxy is not running and needs to be started manually. The pmproxy service is usually started from the &#39;Metrics settings&#39; page of the Cockpit web interface. This flaw affects PCP versions 4.3.4 and newer.(CVE-2024-3019)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="pcp-pmda-activemq" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-activemq-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-zimbra" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-zimbra-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-infiniband" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-infiniband-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-zabbix-agent" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-zabbix-agent-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-gfs2" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-gfs2-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2json" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2json-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-collectl2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-collectl2pcp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-debuginfo" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-debuginfo-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-cifs" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-cifs-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mounts" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mounts-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bpftrace" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bpftrace-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-sendmail" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-sendmail-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-sar2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-sar2pcp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bpf" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bpf-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2graphite" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2graphite-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-gpsd" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-gpsd-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-dbping" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-dbping-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-lustrecomm" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-lustrecomm-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-openmetrics" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-openmetrics-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-zeroconf" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-zeroconf-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-ds389log" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-ds389log-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-apache" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-apache-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-cisco" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-cisco-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2influxdb" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2influxdb-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-oracle" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-oracle-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-hacluster" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-hacluster-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-shping" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-shping-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mysql" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mysql-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-PCP-LogSummary" release="4.oe2203sp1" version="5.3.7">
                         <filename>perl-PCP-LogSummary-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-rabbitmq" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-rabbitmq-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-iostat2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-iostat2pcp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-roomtemp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-roomtemp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-mrtg2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-mrtg2pcp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mongodb" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mongodb-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-import-ganglia2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-ganglia2pcp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2zabbix" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2zabbix-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="pcp-devel" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-devel-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2spark" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2spark-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-podman" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-podman-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-json" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-json-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-haproxy" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-haproxy-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-trace" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-trace-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-redis" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-redis-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-libvirt" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-libvirt-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-system-tools" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-system-tools-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-nfsclient" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-nfsclient-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2xml" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2xml-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-weblog" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-weblog-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-systemd" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-systemd-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-lio" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-lio-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-news" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-news-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mic" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mic-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-PCP-PMDA" release="4.oe2203sp1" version="5.3.7">
                         <filename>perl-PCP-PMDA-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-postgresql" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-postgresql-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-PCP-MMV" release="4.oe2203sp1" version="5.3.7">
                         <filename>perl-PCP-MMV-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-export-pcp2elasticsearch" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2elasticsearch-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-gui" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-gui-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-zswap" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-zswap-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-debugsource" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-debugsource-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>python3-pcp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-lmsensors" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-lmsensors-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-selinux" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-selinux-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-postfix" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-postfix-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-pdns" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-pdns-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-summary" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-summary-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-nutcracker" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-nutcracker-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-rsyslog" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-rsyslog-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-slurm" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-slurm-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-gluster" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-gluster-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-docker" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-docker-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-gpfs" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-gpfs-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-conf" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-conf-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bonding" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bonding-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-elasticsearch" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-elasticsearch-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-mailq" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mailq-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-netfilter" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-netfilter-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-perfevent" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-perfevent-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-samba" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-samba-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-sockets" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-sockets-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-netcheck" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-netcheck-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-dm" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-dm-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-ds389" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-ds389-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-snmp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-snmp-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-logger" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-logger-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-nvidia-gpu" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-nvidia-gpu-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-named" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-named-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bind2" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bind2-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-lustre" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-lustre-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-openvswitch" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-openvswitch-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-nginx" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-nginx-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perl-PCP-LogImport" release="4.oe2203sp1" version="5.3.7">
                         <filename>perl-PCP-LogImport-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-bash" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bash-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-memcache" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-memcache-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-smart" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-smart-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-denki" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-denki-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pcp-pmda-unbound" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-unbound-5.3.7-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="pcp-help" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-help-5.3.7-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2spark" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2spark-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-selinux" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-selinux-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-lustre" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-lustre-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-libvirt" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-libvirt-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2graphite" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2graphite-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-PCP-LogSummary" release="4.oe2203sp1" version="5.3.7">
                         <filename>perl-PCP-LogSummary-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-named" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-named-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-openmetrics" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-openmetrics-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2json" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2json-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bash" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bash-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-samba" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-samba-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-dm" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-dm-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-infiniband" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-infiniband-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-dbping" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-dbping-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-docker" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-docker-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-rsyslog" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-rsyslog-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bind2" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bind2-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-oracle" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-oracle-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-news" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-news-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-hacluster" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-hacluster-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bpftrace" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bpftrace-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-activemq" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-activemq-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-lmsensors" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-lmsensors-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mssql" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mssql-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-debuginfo" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-debuginfo-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-iostat2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-iostat2pcp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-podman" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-podman-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-devel" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-devel-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mic" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mic-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-cisco" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-cisco-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-elasticsearch" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-elasticsearch-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-summary" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-summary-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-ganglia2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-ganglia2pcp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-systemd" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-systemd-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-postfix" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-postfix-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-PCP-MMV" release="4.oe2203sp1" version="5.3.7">
                         <filename>perl-PCP-MMV-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-openvswitch" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-openvswitch-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-sar2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-sar2pcp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-perfevent" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-perfevent-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-gluster" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-gluster-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2xml" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2xml-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-conf" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-conf-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-apache" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-apache-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mounts" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mounts-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2elasticsearch" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2elasticsearch-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-smart" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-smart-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-nvidia-gpu" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-nvidia-gpu-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-nutcracker" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-nutcracker-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-ds389" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-ds389-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-cifs" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-cifs-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-zimbra" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-zimbra-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bcc" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bcc-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-nfsclient" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-nfsclient-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-logger" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-logger-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-slurm" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-slurm-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-sockets" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-sockets-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-zabbix-agent" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-zabbix-agent-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-PCP-PMDA" release="4.oe2203sp1" version="5.3.7">
                         <filename>perl-PCP-PMDA-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-json" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-json-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-system-tools" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-system-tools-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-gpsd" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-gpsd-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2zabbix" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2zabbix-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perl-PCP-LogImport" release="4.oe2203sp1" version="5.3.7">
                         <filename>perl-PCP-LogImport-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>python3-pcp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mysql" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mysql-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-netfilter" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-netfilter-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bonding" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bonding-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-postgresql" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-postgresql-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-shping" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-shping-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-zswap" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-zswap-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mongodb" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mongodb-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-mrtg2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-mrtg2pcp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-gui" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-gui-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-snmp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-snmp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-unbound" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-unbound-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-gfs2" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-gfs2-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-bpf" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-bpf-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-memcache" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-memcache-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-weblog" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-weblog-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-trace" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-trace-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-ds389log" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-ds389log-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-mailq" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-mailq-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-lio" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-lio-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-gpfs" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-gpfs-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-import-collectl2pcp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-import-collectl2pcp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-pdns" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-pdns-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-sendmail" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-sendmail-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-lustrecomm" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-lustrecomm-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-export-pcp2influxdb" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-export-pcp2influxdb-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-haproxy" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-haproxy-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-rabbitmq" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-rabbitmq-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-nginx" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-nginx-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-debugsource" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-debugsource-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-roomtemp" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-roomtemp-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-redis" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-redis-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-netcheck" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-netcheck-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-zeroconf" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-zeroconf-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pcp-pmda-denki" release="4.oe2203sp1" version="5.3.7">
                         <filename>pcp-pmda-denki-5.3.7-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1438</id>
          <title>An update for jpegoptim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-32325" id="CVE-2022-32325" title="CVE-2022-32325" type="cve"></reference>
          </references>
          <description>JPEGOPTIM v1.4.7 was discovered to contain a segmentation violation which is caused by a READ memory access at jpegoptim.c.(CVE-2022-32325)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="jpegoptim-debugsource" release="1.oe2203sp1" version="1.5.5">
                         <filename>jpegoptim-debugsource-1.5.5-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jpegoptim-debuginfo" release="1.oe2203sp1" version="1.5.5">
                         <filename>jpegoptim-debuginfo-1.5.5-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jpegoptim" release="1.oe2203sp1" version="1.5.5">
                         <filename>jpegoptim-1.5.5-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jpegoptim-debuginfo" release="1.oe2203sp1" version="1.5.5">
                         <filename>jpegoptim-debuginfo-1.5.5-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jpegoptim-debugsource" release="1.oe2203sp1" version="1.5.5">
                         <filename>jpegoptim-debugsource-1.5.5-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jpegoptim" release="1.oe2203sp1" version="1.5.5">
                         <filename>jpegoptim-1.5.5-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1439</id>
          <title>An update for gnutls is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28834" id="CVE-2024-28834" title="CVE-2024-28834" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-28834)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnutls-devel" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debugsource" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-utils" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debuginfo" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnutls-help" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-help-3.7.2-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-utils" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debuginfo" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-devel" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debugsource" release="13.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1444</id>
          <title>An update for libgsasl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2469" id="CVE-2022-2469" title="CVE-2022-2469" type="cve"></reference>
          </references>
          <description>GNU SASL libgsasl server-side read-out-of-bounds with malicious authenticated GSS-API client(CVE-2022-2469)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libgsasl-debugsource" release="2.oe2203sp1" version="1.8.1">
                         <filename>libgsasl-debugsource-1.8.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsasl-devel" release="2.oe2203sp1" version="1.8.1">
                         <filename>libgsasl-devel-1.8.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsasl-debuginfo" release="2.oe2203sp1" version="1.8.1">
                         <filename>libgsasl-debuginfo-1.8.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsasl" release="2.oe2203sp1" version="1.8.1">
                         <filename>libgsasl-1.8.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsasl" release="2.oe2203sp1" version="1.8.1">
                         <filename>libgsasl-1.8.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsasl-debuginfo" release="2.oe2203sp1" version="1.8.1">
                         <filename>libgsasl-debuginfo-1.8.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsasl-debugsource" release="2.oe2203sp1" version="1.8.1">
                         <filename>libgsasl-debugsource-1.8.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsasl-devel" release="2.oe2203sp1" version="1.8.1">
                         <filename>libgsasl-devel-1.8.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1446</id>
          <title>An update for LibRaw is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-32142" id="CVE-2021-32142" title="CVE-2021-32142" type="cve"></reference>
          </references>
          <description>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.(CVE-2021-32142)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="LibRaw-debugsource" release="7.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-debugsource-0.20.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw" release="7.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-0.20.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw-debuginfo" release="7.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-debuginfo-0.20.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="LibRaw-devel" release="7.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-devel-0.20.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-debuginfo" release="7.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-debuginfo-0.20.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-debugsource" release="7.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-debugsource-0.20.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw" release="7.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-0.20.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="LibRaw-devel" release="7.oe2203sp1" version="0.20.2">
                         <filename>LibRaw-devel-0.20.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1451</id>
          <title>An update for python-pillow is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28219" id="CVE-2024-28219" title="CVE-2024-28219" type="cve"></reference>
          </references>
          <description>In _imagingcms.c in Pillow before 10.3.0, a buffer overflow exists because strcpy is used instead of strncpy.(CVE-2024-28219)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-pillow-qt" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debuginfo" release="7.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-pillow-debugsource" release="7.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-tk" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-pillow-devel" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pillow-help" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-help-9.0.1-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-qt" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-qt-9.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-9.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debuginfo" release="7.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debuginfo-9.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-tk" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-tk-9.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-pillow-devel" release="7.oe2203sp1" version="9.0.1">
                         <filename>python3-pillow-devel-9.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-pillow-debugsource" release="7.oe2203sp1" version="9.0.1">
                         <filename>python-pillow-debugsource-9.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1452</id>
          <title>An update for mod_http2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27316" id="CVE-2024-27316" title="CVE-2024-27316" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-27316)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mod_http2-debuginfo" release="3.oe2203sp1" version="1.15.25">
                         <filename>mod_http2-debuginfo-1.15.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_http2-debugsource" release="3.oe2203sp1" version="1.15.25">
                         <filename>mod_http2-debugsource-1.15.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_http2" release="3.oe2203sp1" version="1.15.25">
                         <filename>mod_http2-1.15.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="mod_http2-help" release="3.oe2203sp1" version="1.15.25">
                         <filename>mod_http2-help-1.15.25-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_http2" release="3.oe2203sp1" version="1.15.25">
                         <filename>mod_http2-1.15.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_http2-debuginfo" release="3.oe2203sp1" version="1.15.25">
                         <filename>mod_http2-debuginfo-1.15.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_http2-debugsource" release="3.oe2203sp1" version="1.15.25">
                         <filename>mod_http2-debugsource-1.15.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1455</id>
          <title>An update for gstreamer1-plugins-base is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-37328" id="CVE-2023-37328" title="CVE-2023-37328" type="cve"></reference>
          </references>
          <description>Heap-based buffer overflow in the subparse subtitle parser when handling certain SRT subtitle 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-0002.html(CVE-2023-37328)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gstreamer1-plugins-base-debuginfo" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debuginfo-1.18.4-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base-debugsource" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debugsource-1.18.4-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-1.18.4-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gstreamer1-plugins-base-devel" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-devel-1.18.4-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gstreamer1-plugins-base-help" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-help-1.18.4-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-debugsource" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debugsource-1.18.4-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-devel" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-devel-1.18.4-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-1.18.4-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gstreamer1-plugins-base-debuginfo" release="6.oe2203sp1" version="1.18.4">
                         <filename>gstreamer1-plugins-base-debuginfo-1.18.4-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1458</id>
          <title>An update for libdwarf is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2002" id="CVE-2024-2002" title="CVE-2024-2002" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-2002)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="libdwarf" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-0.9.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libdwarf-debugsource" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-debugsource-0.9.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libdwarf-tools" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-tools-0.9.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libdwarf-debuginfo" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-debuginfo-0.9.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="libdwarf-devel" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-devel-0.9.1-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="libdwarf-help" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-help-0.9.1-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libdwarf-debugsource" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-debugsource-0.9.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libdwarf" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-0.9.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libdwarf-debuginfo" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-debuginfo-0.9.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libdwarf-devel" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-devel-0.9.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="libdwarf-tools" release="1.oe2203sp1" version="0.9.1">
                         <filename>libdwarf-tools-0.9.1-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1461</id>
          <title>An update for libssh2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48795" id="CVE-2023-48795" title="CVE-2023-48795" type="cve"></reference>
          </references>
          <description>The SSH transport protocol with certain OpenSSH extensions, found in OpenSSH before 9.6 and other products, allows remote attackers to bypass integrity checks such that some packets are omitted (from the extension negotiation message), and a client and server may consequently end up with a connection for which some security features have been downgraded or disabled, aka a Terrapin attack. This occurs because the SSH Binary Packet Protocol (BPP), implemented by these extensions, mishandles the handshake phase and mishandles use of sequence numbers. For example, there is an effective attack against SSH&#39;s use of ChaCha20-Poly1305 (and CBC with Encrypt-then-MAC). The bypass occurs in chacha20-poly1305@openssh.com and (if CBC is used) the -etm@openssh.com MAC algorithms. This also affects Maverick Synergy Java SSH API before 3.1.0-SNAPSHOT, Dropbear through 2022.83, Ssh before 5.1.1 in Erlang/OTP, PuTTY before 0.80, AsyncSSH before 2.14.2, golang.org/x/crypto before 0.17.0, libssh before 0.10.6, libssh2 through 1.11.0, Thorn Tech SFTP Gateway before 3.4.6, Tera Term before 5.1, Paramiko before 3.4.0, jsch before 0.2.15, SFTPGo before 2.5.6, Netgate pfSense Plus through 23.09.1, Netgate pfSense CE through 2.7.2, HPN-SSH through 18.2.0, ProFTPD before 1.3.8b (and before 1.3.9rc2), ORYX CycloneSSH before 2.3.4, NetSarang XShell 7 before Build 0144, CrushFTP before 10.6.0, ConnectBot SSH library before 2.2.22, Apache MINA sshd through 2.11.0, sshj through 0.37.0, TinySSH through 20230101, trilead-ssh2 6401, LANCOM LCOS and LANconfig, FileZilla before 3.66.4, Nova before 11.8, PKIX-SSH before 14.4, SecureCRT before 9.4.3, Transmit5 before 5.10.4, Win32-OpenSSH before 9.5.0.0p1-Beta, WinSCP before 6.2.2, Bitvise SSH Server before 9.32, Bitvise SSH Client before 9.33, KiTTY through 0.76.1.13, the net-ssh gem 7.2.0 for Ruby, the mscdex ssh2 module before 1.15.0 for Node.js, the thrussh library before 0.35.1 for Rust, and the Russh crate before 0.40.2 for Rust.(CVE-2023-48795)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libssh2-debuginfo" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-debuginfo-1.10.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh2-debugsource" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-debugsource-1.10.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh2-devel" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-devel-1.10.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libssh2" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-1.10.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libssh2-help" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-help-1.10.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh2-debugsource" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-debugsource-1.10.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh2" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-1.10.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh2-debuginfo" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-debuginfo-1.10.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libssh2-devel" release="6.oe2203sp1" version="1.10.0">
                         <filename>libssh2-devel-1.10.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1466</id>
          <title>An update for docker is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29018" id="CVE-2024-29018" title="CVE-2024-29018" type="cve"></reference>
          </references>
          <description>Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. Moby&#39;s networking implementation allows for many networks, each with their own IP address range and gateway, to be defined. This feature is frequently referred to as custom networks, as each network can have a different driver, set of parameters and thus behaviors. When creating a network, the `--internal` flag is used to designate a network as _internal_. The `internal` attribute in a docker-compose.yml file may also be used to mark a network _internal_, and other API clients may specify the `internal` parameter as well.When containers with networking are created, they are assigned unique network interfaces and IP addresses. The host serves as a router for non-internal networks, with a gateway IP that provides SNAT/DNAT to/from container IPs.Containers on an internal network may communicate between each other, but are precluded from communicating with any networks the host has access to (LAN or WAN) as no default route is configured, and firewall rules are set up to drop all outgoing traffic. Communication with the gateway IP address (and thus appropriately configured host services) is possible, and the host may communicate with any container IP directly.In addition to configuring the Linux kernel&#39;s various networking features to enable container networking, `dockerd` directly provides some services to container networks. Principal among these is serving as a resolver, enabling service discovery, and resolution of names from an upstream resolver.When a DNS request for a name that does not correspond to a container is received, the request is forwarded to the configured upstream resolver. This request is made from the container&#39;s network namespace: the level of access and routing of traffic is the same as if the request was made by the container itself.As a consequence of this design, containers solely attached to an internal network will be unable to resolve names using the upstream resolver, as the container itself is unable to communicate with that nameserver. Only the names of containers also attached to the internal network are able to be resolved.Many systems run a local forwarding DNS resolver. As the host and any containers have separate loopback devices, a consequence of the design described above is that containers are unable to resolve names from the host&#39;s configured resolver, as they cannot reach these addresses on the host loopback device. To bridge this gap, and to allow containers to properly resolve names even when a local forwarding resolver is used on a loopback address, `dockerd` detects this scenario and instead forward DNS requests from the host namework namespace. The loopback resolver then forwards the requests to its configured upstream resolvers, as expected.Because `dockerd` forwards DNS requests to the host loopback device, bypassing the container network namespace&#39;s normal routing semantics entirely, internal networks can unexpectedly forward DNS requests to an external nameserver. By registering a domain for which they control the authoritative nameservers, an attacker could arrange for a compromised container to exfiltrate data by encoding it in DNS queries that will eventually be answered by their nameservers.Docker Desktop is not affected, as Docker Desktop always runs an internal resolver on a RFC 1918 address.Moby releases 26.0.0, 25.0.4, and 23.0.11 are patched to prevent forwarding any DNS requests from internal networks. As a workaround, run containers intended to be solely attached to internal networks with a custom upstream address, which will force all upstream DNS queries to be resolved from the container&#39;s network namespace.(CVE-2024-29018)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="docker-engine-debugsource" release="334.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-334.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debuginfo" release="334.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-334.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine" release="334.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-334.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debuginfo" release="334.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-334.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debugsource" release="334.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-334.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine" release="334.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-334.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1470</id>
          <title>An update for gnutls is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28835" id="CVE-2024-28835" title="CVE-2024-28835" type="cve"></reference>
          </references>
          <description>A flaw has been discovered in GnuTLS where an application crash can be induced when attempting to verify a specially crafted .pem bundle using the &#34;certtool --verify-chain&#34; command.(CVE-2024-28835)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnutls-devel" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debuginfo" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debugsource" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-utils" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnutls-help" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-help-3.7.2-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debugsource" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-utils" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-devel" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debuginfo" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1471</id>
          <title>An update for jose is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50967" id="CVE-2023-50967" title="CVE-2023-50967" type="cve"></reference>
          </references>
          <description>latchset jose through version 11 allows attackers to cause a denial of service (CPU consumption) via a large p2c (aka PBES2 Count) value.(CVE-2023-50967)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="jose-devel" release="2.oe2203sp1" version="11">
                         <filename>jose-devel-11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jose" release="2.oe2203sp1" version="11">
                         <filename>jose-11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jose-help" release="2.oe2203sp1" version="11">
                         <filename>jose-help-11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jose-debugsource" release="2.oe2203sp1" version="11">
                         <filename>jose-debugsource-11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jose-debuginfo" release="2.oe2203sp1" version="11">
                         <filename>jose-debuginfo-11-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jose-debugsource" release="2.oe2203sp1" version="11">
                         <filename>jose-debugsource-11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jose-devel" release="2.oe2203sp1" version="11">
                         <filename>jose-devel-11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jose" release="2.oe2203sp1" version="11">
                         <filename>jose-11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jose-help" release="2.oe2203sp1" version="11">
                         <filename>jose-help-11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jose-debuginfo" release="2.oe2203sp1" version="11">
                         <filename>jose-debuginfo-11-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1472</id>
          <title>An update for cri-o is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28180" id="CVE-2024-28180" title="CVE-2024-28180" type="cve"></reference>
          </references>
          <description>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-2024-28180)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cri-o-debugsource" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debugsource-1.23.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cri-o" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-1.23.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cri-o-debuginfo" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debuginfo-1.23.2-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o-debuginfo" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debuginfo-1.23.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-1.23.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cri-o-debugsource" release="11.oe2203sp1" version="1.23.2">
                         <filename>cri-o-debugsource-1.23.2-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1476</id>
          <title>An update for apache-mime4j is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21742" id="CVE-2024-21742" title="CVE-2024-21742" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-21742)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="apache-mime4j-javadoc" release="2.oe2203sp1" version="0.8.3">
                         <filename>apache-mime4j-javadoc-0.8.3-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="apache-mime4j" release="2.oe2203sp1" version="0.8.3">
                         <filename>apache-mime4j-0.8.3-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1481</id>
          <title>An update for llvm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46049" id="CVE-2023-46049" title="CVE-2023-46049" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-46049)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="llvm" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-12.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="llvm-devel" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-devel-12.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="llvm-libs" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-libs-12.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="llvm-debuginfo" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-debuginfo-12.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="llvm-debugsource" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-debugsource-12.0.1-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="llvm-help" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-help-12.0.1-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="llvm" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-12.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="llvm-devel" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-devel-12.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="llvm-libs" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-libs-12.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="llvm-debugsource" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-debugsource-12.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="llvm-debuginfo" release="7.oe2203sp1" version="12.0.1">
                         <filename>llvm-debuginfo-12.0.1-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1486</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47070" id="CVE-2021-47070" title="CVE-2021-47070" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47101" id="CVE-2021-47101" title="CVE-2021-47101" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52464" id="CVE-2023-52464" title="CVE-2023-52464" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52475" id="CVE-2023-52475" title="CVE-2023-52475" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52500" id="CVE-2023-52500" title="CVE-2023-52500" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52507" id="CVE-2023-52507" title="CVE-2023-52507" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52510" id="CVE-2023-52510" title="CVE-2023-52510" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52515" id="CVE-2023-52515" title="CVE-2023-52515" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52516" id="CVE-2023-52516" title="CVE-2023-52516" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52522" id="CVE-2023-52522" title="CVE-2023-52522" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52530" id="CVE-2023-52530" title="CVE-2023-52530" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52560" id="CVE-2023-52560" title="CVE-2023-52560" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52561" id="CVE-2023-52561" title="CVE-2023-52561" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52566" id="CVE-2023-52566" title="CVE-2023-52566" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52568" id="CVE-2023-52568" title="CVE-2023-52568" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52573" id="CVE-2023-52573" title="CVE-2023-52573" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52578" id="CVE-2023-52578" title="CVE-2023-52578" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52583" id="CVE-2023-52583" title="CVE-2023-52583" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52587" id="CVE-2023-52587" title="CVE-2023-52587" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52594" id="CVE-2023-52594" title="CVE-2023-52594" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52595" id="CVE-2023-52595" title="CVE-2023-52595" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52597" id="CVE-2023-52597" title="CVE-2023-52597" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52598" id="CVE-2023-52598" title="CVE-2023-52598" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52622" id="CVE-2023-52622" title="CVE-2023-52622" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Fix another memory leak in error handling pathsMemory allocated by &#39;vmbus_alloc_ring()&#39; at the beginning of the probefunction is never freed in the error handling path.Add the missing &#39;vmbus_free_ring()&#39; call.Note that it is already freed in the .remove function.(CVE-2021-47070)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 casesmsr 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:497BUG: 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-2021-47101)In the Linux kernel, the following vulnerability has been resolved:EDAC/thunderx: Fix possible out-of-bounds string accessEnabling -Wstringop-overflow globally exposes a warning for a common bugin the usage of strncat():  drivers/edac/thunderx_edac.c: In function &#39;thunderx_ocx_com_threaded_isr&#39;:  drivers/edac/thunderx_edac.c:1136:17: error: &#39;strncat&#39; 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 theway that strlcat() does, which uses the size of the destination bufferas its third argument rather than the length of the source buffer. Theresult 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-2023-52464)In the Linux kernel, the following vulnerability has been resolved:Input: powermate - fix use-after-free in powermate_config_completesyzbot has found a use-after-free bug [1] in the powermate driver. Thishappens when the device is disconnected, which leads to a memory free fromthe powermate_device struct.  When an asynchronous control messagecompletes after the kfree and its callback is invoked, the lock does notexist anymore and hence the bug.Use usb_kill_urb() on pm-&gt;config to cancel any in-progress requests upondevice disconnection.[1] https://syzkaller.appspot.com/bug?extid=0434ac83f907a1dbdd1e(CVE-2023-52475)In the Linux kernel, the following vulnerability has been resolved:scsi: pm80xx: Avoid leaking tags when processing OPC_INB_SET_CONTROLLER_CONFIG commandTags allocated for OPC_INB_SET_CONTROLLER_CONFIG command need to be freedwhen we receive the response.(CVE-2023-52500)In the Linux kernel, the following vulnerability has been resolved:nfc: nci: assert requested protocol is validThe protocol is used in a bit mask to determine if the protocol issupported. Assert the provided protocol is less than the maximumdefined so it doesn&#39;t potentially perform a shift-out-of-bounds andprovide a clearer error for undefined protocols vs unsupported ones.(CVE-2023-52507)In the Linux kernel, the following vulnerability has been resolved:ieee802154: ca8210: Fix a potential UAF in ca8210_probeIf of_clk_add_provider() fails in ca8210_register_ext_clock(),it calls clk_unregister() to release priv-&gt;clk and returns anerror. However, the caller ca8210_probe() then calls ca8210_remove(),where priv-&gt;clk is freed again in ca8210_unregister_ext_clock(). Inthis case, a use-after-free may happen in the second time we callclk_unregister().Fix this by removing the first clk_unregister(). Also, priv-&gt;clk couldbe an error code on failure of clk_register_fixed_rate(). UseIS_ERR_OR_NULL to catch this case in ca8210_unregister_ext_clock().(CVE-2023-52510)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_handlercallback, 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 allthe above actions would trigger a use-after-free. Hence remove thescsi_done() call from srp_abort(). Keep the srp_free_req() callbefore returning SUCCESS because we may not see the command again ifSUCCESS is returned.(CVE-2023-52515)In the Linux kernel, the following vulnerability has been resolved:dma-debug: don&#39;t call __dma_entry_alloc_check_leak() under free_entries_lock__dma_entry_alloc_check_leak() calls into printk -&gt; serial consoleoutput (qcom geni) and grabs port-&gt;lock under free_entries_lockspin lock, which is a reverse locking dependency chain as qcom_geniIRQ handler can call into dma-debug code and grab free_entries_lockunder port-&gt;lock.Move __dma_entry_alloc_check_leak() call out of free_entries_lockscope so that we don&#39;t acquire serial console&#39;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-52516)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 anRCU protected item from a list.Readers use rcu_deference(*np), we need to use eitherrcu_assign_pointer() or WRITE_ONCE() on writer sideto prevent store tearing.I use rcu_assign_pointer() to have lockdep support,this was the choice made in neigh_flush_dev().(CVE-2023-52522)In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: fix potential key use-after-freeWhen 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 thekey, in a potential use-after-free. This normally doesn&#39;t happensince it&#39;s only called by iwlwifi in case of WoWLAN rekey offloadwhich has its own KRACK protection, but still better to fix, dothat by returning an error code and converting that to success onthe cfg80211 boundary only, leaving the error for bad callers ofieee80211_gtk_rekey_add().(CVE-2023-52530)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=yand CONFIG_DEBUG_KMEMLEAK_AUTO_SCAN=y, the below memory leak is detected.Since commit 9f86d624292c (&#34;mm/damon/vaddr-test: remove unnecessaryvariables&#34;), the damon_destroy_ctx() is removed, but still calldamon_new_target() and damon_new_region(), the damon_region which isallocated by kmem_cache_alloc() in damon_new_region() and the damon_targetwhich is allocated by kmalloc in damon_new_target() are not freed.  Andthe damon_region which is allocated in damon_new_region() indamon_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 &#34;kunit_try_catch&#34;, 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 &#34;kunit_try_catch&#34;, 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 &#34;kunit_try_catch&#34;, 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 &#34;kunit_try_catch&#34;, 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-52560)In the Linux kernel, the following vulnerability has been resolved:arm64: dts: qcom: sdm845-db845c: Mark cont splash memory region as reservedAdding 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 faultat this particular memory region) reported on DB845c runningv5.10.y.(CVE-2023-52561)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 thereference count of bh when the call to nilfs_dat_translate() fails.  Ifthe reference count hits 0 and its owner page gets unlocked, bh may befreed.  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 releaseoperation after unlocking and putting the page.NOTE: The function in question is only called in GC, and in combinationwith current userland tools, address translation using DAT does not occurin that function, so the code path that causes this issue will not beexecuted.  However, it is possible to run that code path by intentionallymodifying the userland GC library or by calling the GC ioctl directly.[konishi.ryusuke@gmail.com: NOTE added to the commit log](CVE-2023-52566)In the Linux kernel, the following vulnerability has been resolved:x86/sgx: Resolves SECS reclaim vs. page fault for EAUG raceThe SGX EPC reclaimer (ksgxd) may reclaim the SECS EPC page for anenclave and set secs.epc_page to NULL. The SECS page is used for EAUGand ELDU in the SGX page fault handler. However, the NULL check forsecs.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 asneeded for both EAUG and ELDU.The SECS page holds global enclave metadata. It can only be reclaimedwhen there are no other enclave pages remaining. At that point,virtually nothing can be done with the enclave until the SECS page ispaged back in.An enclave can not run nor generate page faults without a resident SECSpage. But it is still possible for a #PF for a non-SECS page to racewith paging out the SECS page: when the last resident non-SECS page Atriggers a #PF in a non-resident page B, and then page A and the SECSboth 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: 0000000000000000RIP: 0010:sgx_encl_eaug_page+0xc7/0x210Call 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-52568)In the Linux kernel, the following vulnerability has been resolved:net: rds: Fix possible NULL-pointer dereferenceIn rds_rdma_cm_event_handler_cmn() check, if conn pointer existsbefore dereferencing it as rdma_set_service_type() argumentFound by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2023-52573)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_finishread-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 1:br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189br_nf_hook_thresh+0x1ed/0x220br_nf_pre_routing_finish_ipv6+0x50f/0x540NF_HOOK include/linux/netfilter.h:304 [inline]br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508nf_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:5637process_backlog+0x21f/0x380 net/core/dev.c:5965__napi_poll+0x60/0x3b0 net/core/dev.c:6527napi_poll net/core/dev.c:6594 [inline]net_rx_action+0x32b/0x750 net/core/dev.c:6727__do_softirq+0xc1/0x265 kernel/softirq.c:553run_ksoftirqd+0x17/0x20 kernel/softirq.c:921smpboot_thread_fn+0x30a/0x4a0 kernel/smpboot.c:164kthread+0x1d7/0x210 kernel/kthread.c:388ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304read-write to 0xffff8881374b2178 of 8 bytes by interrupt on cpu 0:br_handle_frame_finish+0xd4f/0xef0 net/bridge/br_input.c:189br_nf_hook_thresh+0x1ed/0x220br_nf_pre_routing_finish_ipv6+0x50f/0x540NF_HOOK include/linux/netfilter.h:304 [inline]br_nf_pre_routing_ipv6+0x1e3/0x2a0 net/bridge/br_netfilter_ipv6.c:178br_nf_pre_routing+0x526/0xba0 net/bridge/br_netfilter_hooks.c:508nf_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:5637process_backlog+0x21f/0x380 net/core/dev.c:5965__napi_poll+0x60/0x3b0 net/core/dev.c:6527napi_poll net/core/dev.c:6594 [inline]net_rx_action+0x32b/0x750 net/core/dev.c:6727__do_softirq+0xc1/0x265 kernel/softirq.c:553do_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:210spin_unlock_bh include/linux/spinlock.h:396 [inline]batadv_tt_local_purge+0x1a8/0x1f0 net/batman-adv/translation-table.c:1356batadv_tt_purge+0x2b/0x630 net/batman-adv/translation-table.c:3560process_one_work kernel/workqueue.c:2630 [inline]process_scheduled_works+0x5b8/0xa30 kernel/workqueue.c:2703worker_thread+0x525/0x730 kernel/workqueue.c:2784kthread+0x1d7/0x210 kernel/kthread.c:388ret_from_fork+0x48/0x60 arch/x86/kernel/process.c:147ret_from_fork_asm+0x11/0x20 arch/x86/entry/entry_64.S:304value changed: 0x00000000000d7190 -&gt; 0x00000000000d7191Reported 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-52578)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 shouldalways make sure that the parent get the lock first.But since this deadcode is never used and the parent dir will alwaysbe set from the callers, let&#39;s just remove it.(CVE-2023-52583)In the Linux kernel, the following vulnerability has been resolved:IB/ipoib: Fix mcast list lockingReleasing the `priv-&gt;lock` while iterating the `priv-&gt;multicast_list` in`ipoib_mcast_join_task()` opens a window for `ipoib_mcast_dev_flush()` toremove the items while in the middle of iteration. If the mcast is removedwhile the lock was dropped, the for loop spins forever resulting in a hardlockup (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&#39;s stack.)Fix this by keeping the lock held and changing to GFP_ATOMIC to preventeventual sleeps.Unfortunately we could not reproduce the lockup and confirm this fix butbased on the code review I think this fix should address such lockups.crash&gt; bc 31PID: 747      TASK: ff1c6a1a007e8000  CPU: 31   COMMAND: &#34;kworker/u72:2&#34;--    [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 ffffffff9bf10967crash&gt; rx ff646f199a8c7e68ff646f199a8c7e68:  ff1c6a1a04dc82f8 &lt;&lt;&lt; work = &amp;priv-&gt;mcast_task.workcrash&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 = 0xff1c69998efec000crash&gt; b 8PID: 8        TASK: ff1c69998efec000  CPU: 33   COMMAND: &#34;kworker/u72:0&#34;-- #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-2023-52587)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 bugoccurs when txs-&gt;cnt, data from a URB provided by a USB device, isbigger than the size of the array txs-&gt;txstatus, which isHTC_MAX_TX_STATUS. WARN_ON() already checks it, but there is no bughandling code after the check. Make the function return if that is thecase.Found by a modified version of syzkaller.UBSAN: array-index-out-of-bounds in htc_drv_txrx.cindex 13 is out of range for type &#39;__wmi_event_txstatus [12]&#39;Call Trace: ath9k_htc_txstatus ath9k_wmi_event_tasklet tasklet_action_common __do_softirq irq_exit_rxu sysvec_apic_timer_interrupt(CVE-2023-52594)In the Linux kernel, the following vulnerability has been resolved:wifi: rt2x00: restart beacon queue when hardware resetWhen a hardware reset is triggered, all registers are reset, so allqueues are forced to stop in hardware interface. However, mac80211will not automatically stop the queue. If we don&#39;t manually stop thebeacon queue, the queue will be deadlocked and unable to start again.This patch fixes the issue where Apple devices cannot connect to theAP after calling ieee80211_restart_hw().(CVE-2023-52595)In the Linux kernel, the following vulnerability has been resolved:KVM: s390: fix setting of fpc registerkvm_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 bytemporarily 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 fpcregister, and within interrupt context floating point or vector registersare 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 registerswhen returning to user space.test_fp_ctl() restores the original user space / host process fpc registervalue, however it will be discarded, when returning to user space.In result the host process will incorrectly continue to run with the valuethat was supposed to be used for a guest cpu.Fix this by simply removing the test. There is another test right beforethe SIE context is entered which will handles invalid values.This results in a change of behaviour: invalid values will now be acceptedinstead 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 inaddition the same behaviour implemented with the memory mapped interface(replace invalid values with zero) - see sync_regs() in kvm-s390.c.(CVE-2023-52597)In the Linux kernel, the following vulnerability has been resolved:s390/ptrace: handle setting of fpc register correctlyIf the content of the floating point control (fpc) register of a tracedprocess is modified with the ptrace interface the new value is tested forvalidity 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 thefpc register, and within interrupt context floating point or vectorregisters are used, the current fp/vx registers are saved withsave_fpu_regs() assuming they belong to user space and will be loaded intofp/vx registers when returning to user space.test_fp_ctl() restores the original user space fpc register value, howeverit will be discarded, when returning to user space.In result the tracer will incorrectly continue to run with the value thatwas supposed to be used for the traced process.Fix this by saving fpu register contents with save_fpu_regs() before usingtest_fp_ctl().(CVE-2023-52598)In the Linux kernel, the following vulnerability has been resolved:ext4: avoid online resizing failures due to oversized flex bgWhen 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 16Gthe following WARN_ON is triggered:==================================================================WARNING: CPU: 0 PID: 427 at mm/page_alloc.c:4402 __alloc_pages+0x411/0x550Modules linked in: sg(E)CPU: 0 PID: 427 Comm: resize2fs Tainted: G  E  6.6.0-rc5+ #314RIP: 0010:__alloc_pages+0x411/0x550Call 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_dataarray to be allocated exceeds MAX_ORDER. Currently, the minimum value ofMAX_ORDER is 8, the minimum value of PAGE_SIZE is 4096, the correspondingmaximum number of groups that can be allocated is: (PAGE_SIZE &lt;&lt; MAX_ORDER) / sizeof(struct ext4_new_group_data) ≈ 21845And 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 addedeach time does not exceed this value during resizing, and is added multipletimes to complete the online resizing. The difference is that the metadatain a flex_bg may be more dispersed.(CVE-2023-52622)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="3" arch="aarch64" name="python3-perf-debuginfo" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.72.0.152.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="kernel-source" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.72.0.152.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.72.0.152.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1488</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45288" id="CVE-2023-45288" title="CVE-2023-45288" type="cve"></reference>
          </references>
          <description>An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request&#39;s headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.(CVE-2023-45288)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="32.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="32.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="golang-devel" release="32.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="32.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1489</id>
          <title>An update for systemd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50387" id="CVE-2023-50387" title="CVE-2023-50387" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"></reference>
          </references>
          <description>Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the &#34;KeyTrap&#34; issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.(CVE-2023-50387)The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the &#34;NSEC3&#34; issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.(CVE-2023-50868)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="systemd-debugsource" release="75.oe2203sp1" version="249">
                         <filename>systemd-debugsource-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-container" release="75.oe2203sp1" version="249">
                         <filename>systemd-container-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-devel" release="75.oe2203sp1" version="249">
                         <filename>systemd-devel-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd" release="75.oe2203sp1" version="249">
                         <filename>systemd-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-libs" release="75.oe2203sp1" version="249">
                         <filename>systemd-libs-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-debuginfo" release="75.oe2203sp1" version="249">
                         <filename>systemd-debuginfo-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-timesyncd" release="75.oe2203sp1" version="249">
                         <filename>systemd-timesyncd-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-pam" release="75.oe2203sp1" version="249">
                         <filename>systemd-pam-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-udev" release="75.oe2203sp1" version="249">
                         <filename>systemd-udev-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-networkd" release="75.oe2203sp1" version="249">
                         <filename>systemd-networkd-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-nspawn" release="75.oe2203sp1" version="249">
                         <filename>systemd-nspawn-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="systemd-resolved" release="75.oe2203sp1" version="249">
                         <filename>systemd-resolved-249-75.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="systemd-help" release="75.oe2203sp1" version="249">
                         <filename>systemd-help-249-75.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-networkd" release="75.oe2203sp1" version="249">
                         <filename>systemd-networkd-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-pam" release="75.oe2203sp1" version="249">
                         <filename>systemd-pam-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-debuginfo" release="75.oe2203sp1" version="249">
                         <filename>systemd-debuginfo-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-udev" release="75.oe2203sp1" version="249">
                         <filename>systemd-udev-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-timesyncd" release="75.oe2203sp1" version="249">
                         <filename>systemd-timesyncd-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-debugsource" release="75.oe2203sp1" version="249">
                         <filename>systemd-debugsource-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-devel" release="75.oe2203sp1" version="249">
                         <filename>systemd-devel-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-libs" release="75.oe2203sp1" version="249">
                         <filename>systemd-libs-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-container" release="75.oe2203sp1" version="249">
                         <filename>systemd-container-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd" release="75.oe2203sp1" version="249">
                         <filename>systemd-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-nspawn" release="75.oe2203sp1" version="249">
                         <filename>systemd-nspawn-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="systemd-resolved" release="75.oe2203sp1" version="249">
                         <filename>systemd-resolved-249-75.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1490</id>
          <title>An update for flatpak is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32462" id="CVE-2024-32462" title="CVE-2024-32462" type="cve"></reference>
          </references>
          <description>Flatpak is a system for building, distributing, and running sandboxed desktop applications on Linux. in versions before 1.10.9, 1.12.9, 1.14.6, and 1.15.8, a malicious or compromised Flatpak app could execute arbitrary code outside its sandbox. Normally, the `--command` argument of `flatpak run` expects to be given a command to run in the specified Flatpak app, optionally along with some arguments. However it is possible to instead pass `bwrap` arguments to `--command=`, such as `--bind`. It&#39;s possible to pass an arbitrary `commandline` to the portal interface `org.freedesktop.portal.Background.RequestBackground` from within a Flatpak app. When this is converted into a `--command` and arguments, it achieves the same effect of passing arguments directly to `bwrap`, and thus can be used for a sandbox escape. The solution is to pass the `--` argument to `bwrap`, which makes it stop processing options. This has been supported since bubblewrap 0.3.0. All supported versions of Flatpak require at least that version of bubblewrap. xdg-desktop-portal version 1.18.4 will mitigate this vulnerability by only allowing Flatpak apps to create .desktop files for commands that do not start with --. The vulnerability is patched in 1.15.8, 1.10.9, 1.12.9, and 1.14.6.(CVE-2024-32462)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="flatpak-debugsource" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debugsource-1.10.2-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-debuginfo" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debuginfo-1.10.2-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-1.10.2-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-devel" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-devel-1.10.2-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="flatpak-help" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-help-1.10.2-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-debuginfo" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debuginfo-1.10.2-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-devel" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-devel-1.10.2-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-debugsource" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debugsource-1.10.2-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak" release="8.oe2203sp1" version="1.10.2">
                         <filename>flatpak-1.10.2-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1499</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52441" id="CVE-2023-52441" title="CVE-2023-52441" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52486" id="CVE-2023-52486" title="CVE-2023-52486" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52491" id="CVE-2023-52491" title="CVE-2023-52491" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52492" id="CVE-2023-52492" title="CVE-2023-52492" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52493" id="CVE-2023-52493" title="CVE-2023-52493" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52494" id="CVE-2023-52494" title="CVE-2023-52494" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52498" id="CVE-2023-52498" title="CVE-2023-52498" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52503" id="CVE-2023-52503" title="CVE-2023-52503" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52504" id="CVE-2023-52504" title="CVE-2023-52504" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52524" id="CVE-2023-52524" title="CVE-2023-52524" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52574" id="CVE-2023-52574" title="CVE-2023-52574" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52607" id="CVE-2023-52607" title="CVE-2023-52607" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52608" id="CVE-2023-52608" title="CVE-2023-52608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52617" id="CVE-2023-52617" title="CVE-2023-52617" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7042" id="CVE-2023-7042" title="CVE-2023-7042" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24861" id="CVE-2024-24861" title="CVE-2024-24861" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26608" id="CVE-2024-26608" title="CVE-2024-26608" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26615" id="CVE-2024-26615" title="CVE-2024-26615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26654" id="CVE-2024-26654" title="CVE-2024-26654" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26656" id="CVE-2024-26656" title="CVE-2024-26656" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26696" id="CVE-2024-26696" title="CVE-2024-26696" type="cve"></reference>
          </references>
          <description>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 negotiaterequest, init_smb2_rsp_hdr is called for smb1 negotiate request sinceneed_neg is set to false. This patch ignore smb1 packets after -&gt;need_negis set to false.(CVE-2023-52441)In the Linux kernel, the following vulnerability has been resolved:drm: Don&#39;t unref the same fb many times by mistake due to deadlock handlingIf 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 thenget another error during the retry, before the fb lookup, we proceedthe unref the same fb again without having gotten another reference.The end result is that the fb will (eventually) end up being freedwhile it&#39;s still in use.Reset fb to NULL once we&#39;ve unreffed it to avoid doing it againuntil we&#39;ve done another fb lookup.This turned out to be pretty easy to hit on a DG2 when doing asyncflips (and CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y). The first symptom Isaw that drm_closefb() simply got stuck in a busy loop while walkingthe framebuffer list. Fortunately I was able to convince it to oopsinstead, and from there it was easier to track down the culprit.(CVE-2023-52486)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_runIn mtk_jpeg_probe, &amp;jpeg-&gt;job_timeout_work is bound withmtk_jpeg_job_timeout_work.In mtk_jpeg_dec_device_run, if error happens inmtk_jpeg_set_dec_dst, it will finally start the worker whilemark the job as finished by invoking v4l2_m2m_job_finish.There are two methods to trigger the bug. If we remove themodule, it which will call mtk_jpeg_remove to make cleanup.The possible sequence is as follows, which will cause ause-after-free bug.CPU0                  CPU1mtk_jpeg_dec_...    |  start worker&#x9;    |                    |mtk_jpeg_job_timeout_workmtk_jpeg_remove     |  v4l2_m2m_release  |    kfree(m2m_dev); |                    |                    | v4l2_m2m_get_curr_priv                    |   m2m_dev-&gt;curr_ctx //useIf 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 workersuccessfully. Then v4l2_m2m_job_finish will only be called ineither mtk_jpeg_job_timeout_work or mtk_jpeg_dec_device_run.(CVE-2023-52491)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 orintentionally by DMA controller driver), channels are unconditionallyunregistered, 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/0xc0Look at dma_async_device_register() function error path, channel deviceunregistration 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 pointerissue whatever the API used to reach this function.(CVE-2023-52492)In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Drop chan lock before queuing buffersEnsure read and write locks for the channel are not taken in succession bydropping the read lock from parse_xfer_event() such that a callback givento client can potentially queue buffers and acquire the write lock in thatprocess. Any queueing of buffers should be done without channel read lockacquired as it can result in multiple locks and a soft lockup.[mani: added fixes tag and cc&#39;ed stable](CVE-2023-52493)In the Linux kernel, the following vulnerability has been resolved:bus: mhi: host: Add alignment check for event ring read pointerThough we do check the event ring read pointer by &#34;is_valid_ring_ptr&#34;to make sure it is in the buffer range, but there is another risk thepointer may be not aligned.  Since we are expecting event ring elementsare 128 bits(struct mhi_ring_element) aligned, an unaligned read pointercould lead to multiple issues like DoS or ring buffer memory corruption.So add a alignment check for event ring read pointer.(CVE-2023-52494)In the Linux kernel, the following vulnerability has been resolved:PM: sleep: Fix possible deadlocks in core system-wide PM codeIt is reported that in low-memory situations the system-wide resume corecode deadlocks, because async_schedule_dev() executes its argumentfunction synchronously if it cannot allocate memory (and not only inthat case) and that function attempts to acquire a mutex that is alreadyheld.  Executing the argument function synchronously from withindpm_async_fn() may also be problematic for ordering reasons (it maycause a consumer device&#39;s resume callback to be invoked before arequisite supplier device&#39;s one, for example).Address this by changing the code in question to useasync_schedule_dev_nocall() for scheduling the asynchronousexecution of device suspend and resume functions and to directlyrun them synchronously if async_schedule_dev_nocall() returns false.(CVE-2023-52498)In the Linux kernel, the following vulnerability has been resolved:tee: amdtee: fix use-after-free vulnerability in amdtee_close_sessionThere is a potential race condition in amdtee_close_session that maycause use-after-free in amdtee_open_session. For instance, if a sessionhas 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 tocall destroy_session(). However, if in another thread,amdtee_open_session() is called before destroy_session() has completedexecution, alloc_session() may return &#39;sess&#39; that will be freed uplater in destroy_session() leading to use-after-free inamdtee_open_session.To fix this issue, treat decrement of sess-&gt;refcount and removal of&#39;sess&#39; from session list in destroy_session() as a critical section, sothat it is executed atomically.(CVE-2023-52503)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() ona 5-level paging machine:&#x9;BUG: KASAN: out-of-bounds in rcu_is_watching()&#x9;Read of size 4 at addr ff110003ee6419a0 by task swapper/0/0&#x9;...&#x9;__asan_load4()&#x9;rcu_is_watching()&#x9;trace_hardirqs_on()&#x9;text_poke_early()&#x9;apply_alternatives()&#x9;...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 theKASAN_SHADOW_START users. A test patch that makes KASAN_SHADOW_STARTstatic, 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-2023-52504)In the Linux kernel, the following vulnerability has been resolved:net: nfc: llcp: Add lock when modifying device listThe device list needs its associated lock held when modifying it, or thelist could become corrupted, as syzbot discovered.(CVE-2023-52524)In the Linux kernel, the following vulnerability has been resolved:team: fix null-ptr-deref when team device type is changedGet 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 &#39;{&#34;runner&#34;: {&#34;name&#34;: &#34;loadbalance&#34;}}&#39;$ 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 team0When enslave a vlan device to team device and team device type is changedfrom non-ether to ether, header_ops of team device is changed tovlan_header_ops. That is incorrect and will trigger null-ptr-dereffor vlan-&gt;real_dev in vlan_dev_hard_header() because team device is nota vlan device.Cache eth_header_ops in team_setup(), then assign cached header_ops toheader_ops of team net device when its type is changed from non-etherto ether to fix the bug.(CVE-2023-52574)In the Linux kernel, the following vulnerability has been resolved:powerpc/mm: Fix null-pointer dereference in pgtable_cache_addkasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure. Ensure the allocation was successfulby checking the pointer validity.(CVE-2023-52607)In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Check mailbox/SMT channel for consistencyOn reception of a completion interrupt the shared memory area is accessedto retrieve the message header at first and then, if the message sequencenumber identifies a transaction which is still pending, the relatedpayload is fetched too.When an SCMI command times out the channel ownership remains with theplatform until eventually a late reply is received and, as a consequence,any further transmission attempt remains pending, waiting for the channelto be relinquished by the platform.Once that late reply is received the channel ownership is given backto the agent and any pending request is then allowed to proceed andoverwrite the SMT area of the just delivered late reply; then the waitfor the reply to the new request starts.It has been observed that the spurious IRQ related to the late reply canbe wrongly associated with the freshly enqueued request: when that happensthe SCMI stack in-flight lookup procedure is fooled by the fact that themessage header now present in the SMT area is related to the new pendingtransaction, even though the real reply has still to arrive.This race-condition on the A2P channel can be detected by looking at thechannel status bits: a genuine reply from the platform will have set thechannel free bit before triggering the completion IRQ.Add a consistency check to validate such condition in the A2P ISR.(CVE-2023-52608)In the Linux kernel, the following vulnerability has been resolved:PCI: switchtec: Fix stdev_release() crash after surprise hot removeA PCI device hot removal may occur while stdev-&gt;cdev is held open. The callto stdev_release() then happens during close or exit, at a point way pastswitchtec_pci_remove(). Otherwise the last ref would vanish with thetrailing put_device(), just before return.At that later point in time, the devm cleanup has already removed thestdev-&gt;mmio_mrpc mapping. Also, the stdev-&gt;pdev reference was not a countedone. Therefore, in DMA mode, the iowrite32() in stdev_release() will causea 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(), afterstdev_kill(). Counting the stdev-&gt;pdev ref is now optional, but may preventfuture accidents.Reproducible via the script athttps://lore.kernel.org/r/20231113212150.96410-1-dns@arista.com(CVE-2023-52617)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-7042)A race condition was found in the Linux kernel&#39;s media/xc4000 device driver in xc4000 xc4000_get_frequency() function. This can result in return value overflow issue, possibly leading to malfunction or denial of service issue.(CVE-2024-24861)In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix global oob in ksmbd_nl_policySimilar to a reported issue (check the commit b33fb5b801c6 (&#34;net:qualcomm: rmnet: fix global oob in rmnet_policy&#34;), my local fuzzer findsanother global out-of-bounds read for policy ksmbd_nl_policy. See bugtrace 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:600Read of size 1 at addr ffffffff8f24b100 by task syz-executor.1/62810CPU: 0 PID: 62810 Comm: syz-executor.1 Tainted: G                 N 6.1.0 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014Call 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/0xcdRIP: 0033:0x7fdd66a8f359Code: 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 48RSP: 002b:00007fdd65e00168 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007fdd66bbcf80 RCX: 00007fdd66a8f359RDX: 0000000000000000 RSI: 0000000020000500 RDI: 0000000000000003RBP: 00007fdd66ada493 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 00007ffc84b81aff R14: 00007fdd65e00300 R15: 0000000000022000 &lt;/TASK&gt;The buggy address belongs to the variable: ksmbd_nl_policy+0x100/0xa80The buggy address belongs to the physical page:page:0000000034f47940 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1ccc4bflags: 0x200000000001000(reserved|node=0|zone=2)raw: 0200000000001000 ffffea00073312c8 ffffea00073312c8 0000000000000000raw: 0000000000000000 0000000000000000 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedMemory 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 letKSMBD_EVENT_MAX to be its original value - 1 according to what othernetlink families do. Also change two sites that refer theKSMBD_EVENT_MAX to correct value.(CVE-2024-26608)In the Linux kernel, the following vulnerability has been resolved:net/smc: fix illegal rmb_desc access in SMC-D connection dumpA crash was found when dumping SMC-D connections. It can be reproducedby following steps:- run nginx/wrk test:  smc_run nginx  smc_run wrk -t 16 -c 1000 -d &lt;duration&gt; -H &#39;Connection: Close&#39; &lt;URL&gt;- continuously dump SMC-D connections in parallel:  watch -n 1 &#39;smcss -D&#39; BUG: kernel NULL pointer dereference, address: 0000000000000030 CPU: 2 PID: 7204 Comm: smcss Kdump: loaded Tainted: G&#x9;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/0x76It is possible that the connection is in process of being establishedwhen we dump it. Assumed that the connection has been registered in alink group by smc_conn_create() but the rmb_desc has not yet beeninitialized by smc_buf_create(), thus causing the illegal access toconn-&gt;rmb_desc. So fix it by checking before dump.(CVE-2024-26615)In the Linux kernel, the following vulnerability has been resolved:ALSA: sh: aica: reorder cleanup operations to avoid UAF bugsThe dreamcastcard-&gt;timer could schedule the spu_dma_work and thespu_dma_work could also arm the dreamcastcard-&gt;timer.When the snd_pcm_substream is closing, the aica_channel will bedeallocated. But it could still be dereferenced in the workerthread. The reason is that del_timer() will return directlyregardless of whether the timer handler is running or not andthe 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; //USEIn order to mitigate this bug and other possible corner cases,call mod_timer() conditionally in run_spu_dma(), then implementPCM sync_stop op to cancel both the timer and worker. The sync_stopop will be called from PCM core appropriately when needed.(CVE-2024-26654)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix use-after-free bugThe bug can be triggered by sending a single amdgpu_gem_userptr_ioctlto 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){&#x9;struct drm_amdgpu_gem_userptr arg;&#x9;int ret;&#x9;arg.addr = 0xffffffffffff0000;&#x9;arg.size = 0x80000000; /*2 Gb*/&#x9;arg.flags = 0x7;&#x9;ret = drmIoctl(fd, 0xc1186451/*amdgpu_gem_userptr_ioctl*/, &amp;arg);}Due to the address and size are not valid there is a failure inamdgpu_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 callamdgpu_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-2024-26656)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 tocomplete, the log writer thread that should bring the writeback tocompletion picks up the folio being written back innilfs_lookup_dirty_data_buffers() that it calls for subsequent logcreation and was trying to lock the folio.  Thus causing a deadlock.In the first place, it is unexpected that folios/pages in the middle ofwriteback will be updated and become dirty.  Nilfs2 adds a checksum toverify the validity of the log being written and uses it for recovery atmount, so data changes during writeback are suppressed.  Since this isbroken, an unclean shutdown could potentially cause recovery to fail.Investigation revealed that the root cause is that the wait for writebackcompletion in nilfs_page_mkwrite() is conditional, and if the backingdevice does not require stable writes, data may be modified withoutwaiting.Fix these issues by making nilfs_page_mkwrite() wait for writeback tofinish regardless of the stable write requirement of the backing device.(CVE-2024-26696)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="5" arch="aarch64" name="kernel-source" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.73.0.153.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.73.0.153.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.73.0.153.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1509</id>
          <title>An update for ignition is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
          </references>
          <description>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-41723)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ignition" release="5.oe2203sp1" version="2.14.0">
                         <filename>ignition-2.14.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition-validate" release="5.oe2203sp1" version="2.14.0">
                         <filename>ignition-validate-2.14.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition-debugsource" release="5.oe2203sp1" version="2.14.0">
                         <filename>ignition-debugsource-2.14.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ignition-debuginfo" release="5.oe2203sp1" version="2.14.0">
                         <filename>ignition-debuginfo-2.14.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition" release="5.oe2203sp1" version="2.14.0">
                         <filename>ignition-2.14.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-debuginfo" release="5.oe2203sp1" version="2.14.0">
                         <filename>ignition-debuginfo-2.14.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-debugsource" release="5.oe2203sp1" version="2.14.0">
                         <filename>ignition-debugsource-2.14.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ignition-validate" release="5.oe2203sp1" version="2.14.0">
                         <filename>ignition-validate-2.14.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1513</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"></reference>
          </references>
          <description>Issue summary: Some non-default TLS server configurations can cause unboundedmemory growth when processing TLSv1.3 sessionsImpact summary: An attacker may exploit certain server configurations to triggerunbounded memory growth that would lead to a Denial of ServiceThis problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option isbeing used (but not if early_data support is also configured and the defaultanti-replay protection is in use). In this case, under certain conditions, thesession cache can get into an incorrect state and it will fail to flush properlyas it fills. The session cache will continue to grow in an unbounded manner. Amalicious client could deliberately create the scenario for this failure toforce 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 TLSclients.The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL1.0.2 is also not affected by this issue.(CVE-2024-2511)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="17.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="17.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="17.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="17.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="17.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="17.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="17.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="17.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="17.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="17.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1514</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-44488" id="CVE-2023-44488" title="CVE-2023-44488" type="cve"></reference>
          </references>
          <description>VP9 in libvpx before 1.13.1 mishandles widths, leading to a crash related to encoding.(CVE-2023-44488)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox-debugsource" release="6.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="6.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox" release="6.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="6.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="6.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="6.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1515</id>
          <title>An update for freerdp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32039" id="CVE-2024-32039" title="CVE-2024-32039" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32040" id="CVE-2024-32040" title="CVE-2024-32040" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32041" id="CVE-2024-32041" title="CVE-2024-32041" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32458" id="CVE-2024-32458" title="CVE-2024-32458" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32459" id="CVE-2024-32459" title="CVE-2024-32459" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32460" id="CVE-2024-32460" title="CVE-2024-32460" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32658" id="CVE-2024-32658" title="CVE-2024-32658" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32659" id="CVE-2024-32659" title="CVE-2024-32659" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32660" id="CVE-2024-32660" title="CVE-2024-32660" type="cve"></reference>
          </references>
          <description>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-32039)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-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 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-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, use `/gfx` or `/rfx` modes (on by default, require server side support).(CVE-2024-32458)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-32459)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-32460)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-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 if `((nWidth == 0) and (nHeight == 0))`. 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. 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-32660)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="freerdp-debuginfo" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-debuginfo-2.11.7-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libwinpr" release="1.oe2203sp1" version="2.11.7">
                         <filename>libwinpr-2.11.7-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-2.11.7-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-devel" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-devel-2.11.7-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-help" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-help-2.11.7-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libwinpr-devel" release="1.oe2203sp1" version="2.11.7">
                         <filename>libwinpr-devel-2.11.7-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-debugsource" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-debugsource-2.11.7-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-debuginfo" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-debuginfo-2.11.7-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-2.11.7-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-help" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-help-2.11.7-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libwinpr" release="1.oe2203sp1" version="2.11.7">
                         <filename>libwinpr-2.11.7-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-devel" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-devel-2.11.7-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libwinpr-devel" release="1.oe2203sp1" version="2.11.7">
                         <filename>libwinpr-devel-2.11.7-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-debugsource" release="1.oe2203sp1" version="2.11.7">
                         <filename>freerdp-debugsource-2.11.7-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1516</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-04-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0330" id="CVE-2023-0330" title="CVE-2023-0330" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3446" id="CVE-2024-3446" title="CVE-2024-3446" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3447" id="CVE-2024-3447" title="CVE-2024-3447" type="cve"></reference>
          </references>
          <description>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-0330)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.(CVE-2024-3446)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-3447)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-91.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-91.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="91.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-91.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1523</id>
          <title>An update for atril is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51698" id="CVE-2023-51698" title="CVE-2023-51698" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-51698)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="atril-libs" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-libs-1.22.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="atril-devel" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-devel-1.22.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="atril-debugsource" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-debugsource-1.22.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="atril-debuginfo" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-debuginfo-1.22.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="atril" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-1.22.3-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-1.22.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril-debugsource" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-debugsource-1.22.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril-debuginfo" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-debuginfo-1.22.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril-devel" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-devel-1.22.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="atril-libs" release="4.oe2203sp1" version="1.22.3">
                         <filename>atril-libs-1.22.3-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1531</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2511" id="CVE-2024-2511" title="CVE-2024-2511" type="cve"></reference>
          </references>
          <description>Issue summary: Some non-default TLS server configurations can cause unboundedmemory growth when processing TLSv1.3 sessionsImpact summary: An attacker may exploit certain server configurations to triggerunbounded memory growth that would lead to a Denial of ServiceThis problem can occur in TLSv1.3 if the non-default SSL_OP_NO_TICKET option isbeing used (but not if early_data support is also configured and the defaultanti-replay protection is in use). In this case, under certain conditions, thesession cache can get into an incorrect state and it will fail to flush properlyas it fills. The session cache will continue to grow in an unbounded manner. Amalicious client could deliberately create the scenario for this failure toforce 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 TLSclients.The FIPS modules in 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL1.0.2 is also not affected by this issue.(CVE-2024-2511)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="34.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1532</id>
          <title>An update for fdupes is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48682" id="CVE-2022-48682" title="CVE-2022-48682" type="cve"></reference>
          </references>
          <description>In deletefiles in FDUPES before 2.2.0, a TOCTOU race condition allows arbitrary file deletion via a symlink.(CVE-2022-48682)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="fdupes" release="1.oe2203sp1" version="2.3.0">
                         <filename>fdupes-2.3.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="fdupes-debuginfo" release="1.oe2203sp1" version="2.3.0">
                         <filename>fdupes-debuginfo-2.3.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="fdupes-debugsource" release="1.oe2203sp1" version="2.3.0">
                         <filename>fdupes-debugsource-2.3.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="fdupes-help" release="1.oe2203sp1" version="2.3.0">
                         <filename>fdupes-help-2.3.0-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="fdupes-debuginfo" release="1.oe2203sp1" version="2.3.0">
                         <filename>fdupes-debuginfo-2.3.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="fdupes-debugsource" release="1.oe2203sp1" version="2.3.0">
                         <filename>fdupes-debugsource-2.3.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="fdupes" release="1.oe2203sp1" version="2.3.0">
                         <filename>fdupes-2.3.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1533</id>
          <title>An update for python-sqlparse is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4340" id="CVE-2024-4340" title="CVE-2024-4340" type="cve"></reference>
          </references>
          <description>Passing a heavily nested list to sqlparse.parse() leads to a Denial of Service due to RecursionError.(CVE-2024-4340)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-sqlparse" release="3.oe2203sp1" version="0.4.2">
                         <filename>python3-sqlparse-0.4.2-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-sqlparse-help" release="3.oe2203sp1" version="0.4.2">
                         <filename>python-sqlparse-help-0.4.2-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1534</id>
          <title>An update for uriparser is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34402" id="CVE-2024-34402" title="CVE-2024-34402" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34403" id="CVE-2024-34403" title="CVE-2024-34403" type="cve"></reference>
          </references>
          <description>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-34402)An issue was discovered in uriparser through 0.9.7. ComposeQueryMallocExMm in UriQuery.c has an integer overflow via a long string.(CVE-2024-34403)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="uriparser" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-0.9.6-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uriparser-devel" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-devel-0.9.6-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uriparser-debugsource" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-debugsource-0.9.6-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uriparser-debuginfo" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-debuginfo-0.9.6-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="uriparser-help" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-help-0.9.6-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uriparser-debuginfo" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-debuginfo-0.9.6-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uriparser-devel" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-devel-0.9.6-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uriparser" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-0.9.6-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uriparser-debugsource" release="2.oe2203sp1" version="0.9.6">
                         <filename>uriparser-debugsource-0.9.6-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1536</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25739" id="CVE-2024-25739" title="CVE-2024-25739" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26607" id="CVE-2024-26607" title="CVE-2024-26607" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26614" id="CVE-2024-26614" title="CVE-2024-26614" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26644" id="CVE-2024-26644" title="CVE-2024-26644" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26698" id="CVE-2024-26698" title="CVE-2024-26698" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26736" id="CVE-2024-26736" title="CVE-2024-26736" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26751" id="CVE-2024-26751" title="CVE-2024-26751" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26764" id="CVE-2024-26764" title="CVE-2024-26764" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26772" id="CVE-2024-26772" title="CVE-2024-26772" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26773" id="CVE-2024-26773" title="CVE-2024-26773" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26777" id="CVE-2024-26777" title="CVE-2024-26777" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26778" id="CVE-2024-26778" title="CVE-2024-26778" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26788" id="CVE-2024-26788" title="CVE-2024-26788" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26810" id="CVE-2024-26810" title="CVE-2024-26810" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26883" id="CVE-2024-26883" title="CVE-2024-26883" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26884" id="CVE-2024-26884" title="CVE-2024-26884" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26885" id="CVE-2024-26885" title="CVE-2024-26885" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27437" id="CVE-2024-27437" title="CVE-2024-27437" type="cve"></reference>
          </references>
          <description>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-2024-25739)In the Linux kernel, the following vulnerability has been resolved:drm/bridge: sii902x: Fix probing race issueA null pointer dereference crash has been observed rarely on TIplatforms 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/0x20The 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&#39;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 thesii902x_init(), which is also at the very end of sii902x_probe().(CVE-2024-26607)In the Linux kernel, the following vulnerability has been resolved:tcp: make sure init the accept_queue&#39;s spinlocks onceWhen I run syz&#39;s reproduction C program locally, it causes the followingissue:pvqspinlock: lock 0xffff9d181cd5c660 has corrupted value 0x0!WARNING: CPU: 19 PID: 21160 at __pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)Hardware name: Red Hat KVM, BIOS 0.5.1 01/01/2011RIP: 0010:__pv_queued_spin_unlock_slowpath (kernel/locking/qspinlock_paravirt.h:508)Code: 73 56 3a ff 90 c3 cc cc cc cc 8b 05 bb 1f 48 01 85 c0 74 05 c3 cc cc cc cc 8b 17 48 89 fe 48 c7 c730 20 ce 8f e8 ad 56 42 ff &lt;0f&gt; 0b c3 cc cc cc cc 0f 0b 0f 1f 40 00 90 90 90 90 90 90 90 90 90RSP: 0018:ffffa8d200604cb8 EFLAGS: 00010282RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffff9d1ef60e0908RDX: 00000000ffffffd8 RSI: 0000000000000027 RDI: ffff9d1ef60e0900RBP: ffff9d181cd5c280 R08: 0000000000000000 R09: 00000000ffff7fffR10: ffffa8d200604b68 R11: ffffffff907dcdc8 R12: 0000000000000000R13: ffff9d181cd5c660 R14: ffff9d1813a3f330 R15: 0000000000001000FS:  00007fa110184640(0000) GS:ffff9d1ef60c0000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000000 CR3: 000000011f65e000 CR4: 00000000000006f0Call Trace:&lt;IRQ&gt;  _raw_spin_unlock (kernel/locking/spinlock.c:186)  inet_csk_reqsk_queue_add (net/ipv4/inet_connection_sock.c:1321)  inet_csk_complete_hashdance (net/ipv4/inet_connection_sock.c:1358)  tcp_check_req (net/ipv4/tcp_minisocks.c:868)  tcp_v4_rcv (net/ipv4/tcp_ipv4.c:2260)  ip_protocol_deliver_rcu (net/ipv4/ip_input.c:205)  ip_local_deliver_finish (net/ipv4/ip_input.c:234)  __netif_receive_skb_one_core (net/core/dev.c:5529)  process_backlog (./include/linux/rcupdate.h:779)  __napi_poll (net/core/dev.c:6533)  net_rx_action (net/core/dev.c:6604)  __do_softirq (./arch/x86/include/asm/jump_label.h:27)  do_softirq (kernel/softirq.c:454 kernel/softirq.c:441)&lt;/IRQ&gt;&lt;TASK&gt;  __local_bh_enable_ip (kernel/softirq.c:381)  __dev_queue_xmit (net/core/dev.c:4374)  ip_finish_output2 (./include/net/neighbour.h:540 net/ipv4/ip_output.c:235)  __ip_queue_xmit (net/ipv4/ip_output.c:535)  __tcp_transmit_skb (net/ipv4/tcp_output.c:1462)  tcp_rcv_synsent_state_process (net/ipv4/tcp_input.c:6469)  tcp_rcv_state_process (net/ipv4/tcp_input.c:6657)  tcp_v4_do_rcv (net/ipv4/tcp_ipv4.c:1929)  __release_sock (./include/net/sock.h:1121 net/core/sock.c:2968)  release_sock (net/core/sock.c:3536)  inet_wait_for_connect (net/ipv4/af_inet.c:609)  __inet_stream_connect (net/ipv4/af_inet.c:702)  inet_stream_connect (net/ipv4/af_inet.c:748)  __sys_connect (./include/linux/file.h:45 net/socket.c:2064)  __x64_sys_connect (net/socket.c:2073 net/socket.c:2070 net/socket.c:2070)  do_syscall_64 (arch/x86/entry/common.c:51 arch/x86/entry/common.c:82)  entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:129)  RIP: 0033:0x7fa10ff05a3d  Code: 5b 41 5c c3 66 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89  c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d ab a3 0e 00 f7 d8 64 89 01 48  RSP: 002b:00007fa110183de8 EFLAGS: 00000202 ORIG_RAX: 000000000000002a  RAX: ffffffffffffffda RBX: 0000000020000054 RCX: 00007fa10ff05a3d  RDX: 000000000000001c RSI: 0000000020000040 RDI: 0000000000000003  RBP: 00007fa110183e20 R08: 0000000000000000 R09: 0000000000000000  R10: 0000000000000000 R11: 0000000000000202 R12: 00007fa110184640  R13: 0000000000000000 R14: 00007fa10fe8b060 R15: 00007fff73e23b20&lt;/TASK&gt;The issue triggering process is analyzed as follows:Thread A                                       Thread Btcp_v4_rcv&#x9;//receive ack TCP packet       inet_shutdown  tcp_check_req                                  tcp_disconnect //disconnect sock  ...                                              tcp_set_state(sk, TCP_CLOSE)    inet_csk_complete_hashdance                ...      inet_csk_reqsk_queue_add         ---truncated---(CVE-2024-26614)In the Linux kernel, the following vulnerability has been resolved:btrfs: don&#39;t abort filesystem when attempting to snapshot deleted subvolumeIf the source file descriptor to the snapshot ioctl refers to a deletedsubvolume, 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 entryThis happens because create_pending_snapshot() initializes the new rootitem 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() thenfinds the root and returns -ENOENT if refs == 0, which causescreate_pending_snapshot() to abort.Fix it by checking the source root&#39;s refs before attempting thesnapshot, but after locking subvol_sem to avoid racing with deletion.(CVE-2024-26644)In the Linux kernel, the following vulnerability has been resolved:hv_netvsc: Fix race condition between netvsc_probe and netvsc_removeIn commit ac5047671758 (&#34;hv_netvsc: Disable NAPI before closing theVMBus channel&#34;), 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 thesub-channels and because of that netvsc_sc_open() is not running.netvsc_remove() calls cancel_work_sync(&amp;nvdev-&gt;subchan_work), for whichnetvsc_subchan_work did not run.netif_napi_add() sets the bit NAPI_STATE_SCHED because it ensures NAPIcannot be scheduled. Then netvsc_sc_open() -&gt; napi_enable will clear theNAPIF_STATE_SCHED bit, so it can be scheduled. napi_disable() does theopposite.Now during netvsc_device_remove(), when napi_disable is called for thosesubchannels, napi_disable gets stuck on infinite msleep.This fix addresses this problem by ensuring that napi_disable() is notgetting called for non-enabled NAPI struct.But netif_napi_del() is still necessary for these non-enabled NAPI structfor 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-2024-26698)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&#39;s 20 + NUL, so increase it to 24 and use snprintf()](CVE-2024-26736)In the Linux kernel, the following vulnerability has been resolved:ARM: ep93xx: Add terminator to gpiod_lookup_tableWithout the terminator, if a con_id is passed to gpio_find() thatdoes not exist in the lookup table the function will not stop loopingcorrectly, and eventually cause an oops.(CVE-2024-26751)In the Linux kernel, the following vulnerability has been resolved:fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via libaioIf kiocb_set_cancel_fn() is called for I/O submitted via io_uring, thefollowing kernel warning appears:WARNING: CPU: 3 PID: 368 at fs/aio.c:598 kiocb_set_cancel_fn+0x9c/0xa8Call 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/0x1a8Fix this by setting the IOCB_AIO_RW flag for read and write I/O that issubmitted by libaio.(CVE-2024-26764)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&#39;s block bitmap is corrupt underthe protection of the group lock to avoid allocating blocks from the groupwith a corrupted block bitmap.(CVE-2024-26772)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 inext4_mb_try_best_found() to avoid allocating blocks from a group with acorrupted block bitmap in the following concurrency and making thesituation 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&#39;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-2024-26773)In the Linux kernel, the following vulnerability has been resolved:fbdev: sis: Error out if pixclock equals zeroThe userspace program could pass any values to the driver throughioctl() interface. If the driver doesn&#39;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 caculatedrate before it is checked against zero. Fix this by checking itat the beginning.This is similar to CVE-2022-3061 in i740fb which was fixed bycommit 15cf0b8.(CVE-2024-26777)In the Linux kernel, the following vulnerability has been resolved:fbdev: savage: Error out if pixclock equals zeroThe userspace program could pass any values to the driver throughioctl() interface. If the driver doesn&#39;t check the value of pixclock,it may cause divide-by-zero error.Although pixclock is checked in savagefb_decode_var(), but it is notchecked properly in savagefb_probe(). Fix this by checking whetherpixclock is zero in the function savagefb_check_var() beforeinfo-&gt;var.pixclock is used as the divisor.This is similar to CVE-2022-3061 in i740fb which was fixed bycommit 15cf0b8.(CVE-2024-26778)In the Linux kernel, the following vulnerability has been resolved:dmaengine: fsl-qdma: init irq after reg initializationInitialize the qDMA irqs after the registers are configured so thatinterrupts that may have been pending from a primary kernel don&#39;t getprocessed by the irq handler before it is ready to and cause panic withthe 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-26788)In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Lock external INTx masking opsMask operations through config space changes to DisINTx may race INTxconfiguration changes via ioctl.  Create wrappers that add locking forpaths outside of the core interrupt code.In particular, irq_type is updated holding igate, therefore testingis_intx() requires holding igate.  For example clearing DisINTx fromconfig space can otherwise race changes of the interrupt configuration.This aligns interfaces which may trigger the INTx eventfd into twocamps, one side serialized by igate and the other only enabled whileINTx is configured.  A subsequent patch introduces synchronization forthe latter flows.(CVE-2024-26810)In the Linux kernel, the following vulnerability has been resolved:bpf: Fix stackmap overflow check on 32-bit archesThe stackmap code relies on roundup_pow_of_two() to compute the numberof hash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code.The commit in the fixes tag actually attempted to fix this, but the fixdid not account for the UB, so the fix only works on CPUs where anoverflow does result in a neat truncation to zero, which is notguaranteed. Checking the value before rounding does not have thisproblem.(CVE-2024-26883)In the Linux kernel, the following vulnerability has been resolved:bpf: Fix hashtab overflow check on 32-bit archesThe hashtab code relies on roundup_pow_of_two() to compute the number ofhash buckets, and contains an overflow check by checking if theresulting value is 0. However, on 32-bit arches, the roundup code itselfcan overflow by doing a 32-bit left-shift of an unsigned long value,which is undefined behaviour, so it is not guaranteed to truncateneatly. This was triggered by syzbot on the DEVMAP_HASH type, whichcontains the same check, copied from the hashtab code. So apply the samefix to hashtab, by moving the overflow check to before the roundup.(CVE-2024-26884)In the Linux kernel, the following vulnerability has been resolved:bpf: Fix DEVMAP_HASH overflow check on 32-bit archesThe devmap code allocates a number hash buckets equal to the next powerof two of the max_entries value provided when creating the map. Whenrounding up to the next power of two, the 32-bit variable storing thenumber of buckets can overflow, and the code checks for overflow bychecking if the truncated 32-bit value is equal to 0. However, on 32-bitarches the rounding up itself can overflow mid-way through, because itends up doing a left-shift of 32 bits on an unsigned long value. If thesize of an unsigned long is four bytes, this is undefined behaviour, sothere is no guarantee that we&#39;ll end up with a nice and tidy 0-value atthe end.Syzbot managed to turn this into a crash on arm32 by creating aDEVMAP_HASH with max_entries &gt; 0x80000000 and then trying to update it.Fix this by moving the overflow check to before the rounding upoperation.(CVE-2024-26885)In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Disable auto-enable of exclusive INTx IRQCurrently 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 statusflag.  This presents a window where the interrupt could fire betweenthese events, resulting in the IRQ incrementing the disable depth twice.This would be unrecoverable for a user since the masked flag preventsnested enables through vfio.Instead, invert the logic using IRQF_NO_AUTOEN such that exclusive INTxis never auto-enabled, then unmask as required.(CVE-2024-27437)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1542</id>
          <title>An update for freerdp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32661" id="CVE-2024-32661" title="CVE-2024-32661" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-32661)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="freerdp" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-2.11.7-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-help" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-help-2.11.7-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libwinpr" release="2.oe2203sp1" version="2.11.7">
                         <filename>libwinpr-2.11.7-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-debuginfo" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-debuginfo-2.11.7-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="libwinpr-devel" release="2.oe2203sp1" version="2.11.7">
                         <filename>libwinpr-devel-2.11.7-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-debugsource" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-debugsource-2.11.7-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="freerdp-devel" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-devel-2.11.7-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-debuginfo" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-debuginfo-2.11.7-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-2.11.7-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libwinpr-devel" release="2.oe2203sp1" version="2.11.7">
                         <filename>libwinpr-devel-2.11.7-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-debugsource" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-debugsource-2.11.7-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-help" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-help-2.11.7-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="freerdp-devel" release="2.oe2203sp1" version="2.11.7">
                         <filename>freerdp-devel-2.11.7-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="libwinpr" release="2.oe2203sp1" version="2.11.7">
                         <filename>libwinpr-2.11.7-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1546</id>
          <title>An update for sssd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3758" id="CVE-2023-3758" title="CVE-2023-3758" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-3758)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sssd" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-2.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sssd-debuginfo" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-debuginfo-2.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sssd-debugsource" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-debugsource-2.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sssd-devel" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-devel-2.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-sssd" release="14.oe2203sp1" version="2.6.1">
                         <filename>python3-sssd-2.6.1-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sssd-help" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-help-2.6.1-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sssd-debugsource" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-debugsource-2.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sssd-devel" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-devel-2.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-sssd" release="14.oe2203sp1" version="2.6.1">
                         <filename>python3-sssd-2.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sssd-debuginfo" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-debuginfo-2.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sssd" release="14.oe2203sp1" version="2.6.1">
                         <filename>sssd-2.6.1-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1548</id>
          <title>An update for xorg-x11-server-xwayland is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6478" id="CVE-2023-6478" title="CVE-2023-6478" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6816" id="CVE-2023-6816" title="CVE-2023-6816" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0408" id="CVE-2024-0408" title="CVE-2024-0408" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31080" id="CVE-2024-31080" title="CVE-2024-31080" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31081" id="CVE-2024-31081" title="CVE-2024-31081" type="cve"></reference>
          </references>
          <description>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-6478)A flaw was found in X.Org server. Both DeviceFocusEvent and the XIQueryPointer reply contain a bit for each logical button currently down. Buttons can be arbitrarily mapped to any value up to 255, but the X.Org Server was only allocating space for the device&#39;s particular number of buttons, leading to a heap overflow if a bigger value was used.(CVE-2023-6816)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-0408)A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcXIGetSelectedEvents() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.(CVE-2024-31080)A heap-based buffer over-read vulnerability was found in the X.org server&#39;s ProcXIPassiveGrabDevice() function. This issue occurs when byte-swapped length values are used in replies, potentially leading to memory leakage and segmentation faults, particularly when triggered by a client with a different endianness. This vulnerability could be exploited by an attacker to cause the X server to read heap memory values and then transmit them back to the client until encountering an unmapped page, resulting in a crash. Despite the attacker&#39;s inability to control the specific memory copied into the replies, the small length values typically stored in a 32-bit integer can result in significant attempted out-of-bounds reads.(CVE-2024-31081)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debuginfo" release="4.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debugsource" release="4.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-devel" release="4.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland" release="4.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland" release="4.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debugsource" release="4.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-devel" release="4.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debuginfo" release="4.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1552</id>
          <title>An update for cockpit is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-35850" id="CVE-2020-35850" title="CVE-2020-35850" type="cve"></reference>
          </references>
          <description>An SSRF issue was discovered in cockpit-project.org Cockpit 234. NOTE: this is unrelated to the Agentejo Cockpit product. NOTE: the vendor states &#34;I don&#39;t think [it] is a big real-life issue.(CVE-2020-35850)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cockpit-debugsource" release="14.oe2203sp1" version="178">
                         <filename>cockpit-debugsource-178-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit-devel" release="14.oe2203sp1" version="178">
                         <filename>cockpit-devel-178-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit" release="14.oe2203sp1" version="178">
                         <filename>cockpit-178-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit-debuginfo" release="14.oe2203sp1" version="178">
                         <filename>cockpit-debuginfo-178-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-help" release="14.oe2203sp1" version="178">
                         <filename>cockpit-help-178-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-cockpit-machines" release="14.oe2203sp1" version="178">
                         <filename>cockpit-cockpit-machines-178-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-cockpit-machines-ovirt" release="14.oe2203sp1" version="178">
                         <filename>cockpit-cockpit-machines-ovirt-178-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-debuginfo" release="14.oe2203sp1" version="178">
                         <filename>cockpit-debuginfo-178-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-debugsource" release="14.oe2203sp1" version="178">
                         <filename>cockpit-debugsource-178-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-devel" release="14.oe2203sp1" version="178">
                         <filename>cockpit-devel-178-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit" release="14.oe2203sp1" version="178">
                         <filename>cockpit-178-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1553</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38709" id="CVE-2023-38709" title="CVE-2023-38709" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24795" id="CVE-2024-24795" title="CVE-2024-24795" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27316" id="CVE-2024-27316" title="CVE-2024-27316" type="cve"></reference>
          </references>
          <description>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-2023-38709)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-24795)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.(CVE-2024-27316)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-help-2.4.51-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="21.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="21.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1555</id>
          <title>An update for python-tqdm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34062" id="CVE-2024-34062" title="CVE-2024-34062" type="cve"></reference>
          </references>
          <description>tqdm is an open source progress bar for Python and CLI. Any optional non-boolean CLI arguments (e.g. `--delim`, `--buf-size`, `--manpath`) are passed through python&#39;s `eval`, allowing arbitrary code execution. This issue is only locally exploitable and had been addressed in release version 4.66.3. All users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2024-34062)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-tqdm" release="4.oe2203sp1" version="4.56.0">
                         <filename>python3-tqdm-4.56.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-tqdm-help" release="4.oe2203sp1" version="4.56.0">
                         <filename>python-tqdm-help-4.56.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-tqdm" release="4.oe2203sp1" version="4.56.0">
                         <filename>python3-tqdm-4.56.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1561</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6129" id="CVE-2023-6129" title="CVE-2023-6129" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20960" id="CVE-2024-20960" title="CVE-2024-20960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20961" id="CVE-2024-20961" title="CVE-2024-20961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20962" id="CVE-2024-20962" title="CVE-2024-20962" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20963" id="CVE-2024-20963" title="CVE-2024-20963" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20964" id="CVE-2024-20964" title="CVE-2024-20964" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20965" id="CVE-2024-20965" title="CVE-2024-20965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20966" id="CVE-2024-20966" title="CVE-2024-20966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20967" id="CVE-2024-20967" title="CVE-2024-20967" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20969" id="CVE-2024-20969" title="CVE-2024-20969" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20970" id="CVE-2024-20970" title="CVE-2024-20970" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20971" id="CVE-2024-20971" title="CVE-2024-20971" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20972" id="CVE-2024-20972" title="CVE-2024-20972" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20973" id="CVE-2024-20973" title="CVE-2024-20973" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20974" id="CVE-2024-20974" title="CVE-2024-20974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20976" id="CVE-2024-20976" title="CVE-2024-20976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20977" id="CVE-2024-20977" title="CVE-2024-20977" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20978" id="CVE-2024-20978" title="CVE-2024-20978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20981" id="CVE-2024-20981" title="CVE-2024-20981" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20982" id="CVE-2024-20982" title="CVE-2024-20982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20984" id="CVE-2024-20984" title="CVE-2024-20984" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20985" id="CVE-2024-20985" title="CVE-2024-20985" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20993" id="CVE-2024-20993" title="CVE-2024-20993" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20994" id="CVE-2024-20994" title="CVE-2024-20994" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20998" id="CVE-2024-20998" title="CVE-2024-20998" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21000" id="CVE-2024-21000" title="CVE-2024-21000" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21008" id="CVE-2024-21008" title="CVE-2024-21008" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21009" id="CVE-2024-21009" title="CVE-2024-21009" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21013" id="CVE-2024-21013" title="CVE-2024-21013" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21047" id="CVE-2024-21047" title="CVE-2024-21047" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21054" id="CVE-2024-21054" title="CVE-2024-21054" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21055" id="CVE-2024-21055" title="CVE-2024-21055" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21057" id="CVE-2024-21057" title="CVE-2024-21057" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21060" id="CVE-2024-21060" title="CVE-2024-21060" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21061" id="CVE-2024-21061" title="CVE-2024-21061" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21062" id="CVE-2024-21062" title="CVE-2024-21062" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21069" id="CVE-2024-21069" title="CVE-2024-21069" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21096" id="CVE-2024-21096" title="CVE-2024-21096" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21102" id="CVE-2024-21102" title="CVE-2024-21102" type="cve"></reference>
          </references>
          <description>Issue summary: The POLY1305 MAC (message authentication code) implementationcontains a bug that might corrupt the internal state of applications runningon PowerPC CPU based platforms if the CPU provides vector instructions.Impact summary: If an attacker can influence whether the POLY1305 MACalgorithm is used, the application state might be corrupted with variousapplication dependent consequences.The POLY1305 MAC (message authentication code) implementation in OpenSSL forPowerPC CPUs restores the contents of vector registers in a different orderthan they are saved. Thus the contents of some of these vector registersare corrupted when returning to the caller. The vulnerable code is used onlyon newer PowerPC processors supporting the PowerISA 2.07 instructions.The consequences of this kind of internal application state corruption canbe various - from no consequences, if the calling application does notdepend on the contents of non-volatile XMM registers at all, to the worstconsequences, where the attacker could get complete control of the applicationprocess. However unless the compiler uses the vector registers for storingpointers, the most likely consequence, if any, would be an incorrect resultof some application dependent calculations or a crash leading to a denial ofservice.The POLY1305 MAC algorithm is most frequently used as part of theCHACHA20-POLY1305 AEAD (authenticated encryption with associated data)algorithm. The most common usage of this AEAD cipher is with TLS protocolversions 1.2 and 1.3. If this cipher is enabled on the server a maliciousclient can influence whether this AEAD cipher is used. This implies thatTLS server applications using OpenSSL can be potentially impacted. Howeverwe are currently not aware of any concrete application that would be affectedby this issue therefore we consider this a Low severity security issue.(CVE-2023-6129)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-20960)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-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-20962)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-20963)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-20964)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-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-20966)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-20967)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-20969)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-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-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 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-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 high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.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-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-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 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 high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.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-20978)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-20981)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-20982)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-20984)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-20985)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-20993)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-20994)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-20998)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-21000)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-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. Easily exploitable vulnerability allows high privileged attacker with network access via multiple protocols to compromise MySQL Server.  Successful attacks of this vulnerability can result in unauthorized ability to cause a hang or frequently repeatable crash (complete DOS) of MySQL Server. CVSS 3.1 Base Score 4.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. 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-21013)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-21047)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-21054)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-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: 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-21060)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-21061)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: 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-21069)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-21096)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-21102)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-debugsource-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-libs-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-server-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-errmsg-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-test-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-debuginfo-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-devel-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-help-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-common-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-config-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-config-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-debugsource-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-server-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-common-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-test-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-libs-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-devel-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-help-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-debuginfo-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-errmsg-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1564</id>
          <title>An update for sos is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2806" id="CVE-2022-2806" title="CVE-2022-2806" type="cve"></reference>
          </references>
          <description>It was found that the ovirt-log-collector/sosreport collects the RHV admin password unfiltered. Fixed in: sos-4.2-20.el8_6, ovirt-log-collector-4.4.7-2.el8ev(CVE-2022-2806)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="sos" release="6.oe2203sp1" version="4.0">
                         <filename>sos-4.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="sos-help" release="6.oe2203sp1" version="4.0">
                         <filename>sos-help-4.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1565</id>
          <title>An update for libreswan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-05-10"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3652" id="CVE-2024-3652" title="CVE-2024-3652" type="cve"></reference>
          </references>
          <description>The Libreswan Project was notified of an issue causing libreswan to restart when using IKEv1 without specifying an esp= line. When the peer requests AES-GMAC, libreswan&#39;s default proposal handler causes an assertion failure and crashes and restarts. IKEv2 connections are not affected.(CVE-2024-3652)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libreswan" release="1.oe2203sp1" version="4.15">
                         <filename>libreswan-4.15-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debuginfo" release="1.oe2203sp1" version="4.15">
                         <filename>libreswan-debuginfo-4.15-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-debugsource" release="1.oe2203sp1" version="4.15">
                         <filename>libreswan-debugsource-4.15-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libreswan-help" release="1.oe2203sp1" version="4.15">
                         <filename>libreswan-help-4.15-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-help" release="1.oe2203sp1" version="4.15">
                         <filename>libreswan-help-4.15-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debugsource" release="1.oe2203sp1" version="4.15">
                         <filename>libreswan-debugsource-4.15-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan-debuginfo" release="1.oe2203sp1" version="4.15">
                         <filename>libreswan-debuginfo-4.15-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libreswan" release="1.oe2203sp1" version="4.15">
                         <filename>libreswan-4.15-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1570</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-11"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47182" id="CVE-2021-47182" title="CVE-2021-47182" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47211" id="CVE-2021-47211" title="CVE-2021-47211" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26752" id="CVE-2024-26752" title="CVE-2024-26752" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix scsi_mode_sense() buffer length handlingSeveral 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 allocationlength field of MODE SENSE(10) CDB and by returning an error when len istoo 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 ofinvalid opcode error for MODE SENSE(10), access to mode pages larger than255 bytes are not retried using MODE SENSE(6). To avoid buffer lengthoverflows for the MODE_SENSE(10) case, check that len is smaller than 65535bytes.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-2021-47182)In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: fix null pointer dereference on pointer cs_descThe pointer cs_desc return from snd_usb_find_clock_source couldbe null, so there is a potential null pointer dereference issue.Fix this by adding a null check before dereference.(CVE-2021-47211)In the Linux kernel, the following vulnerability has been resolved:l2tp: pass correct message length to ip6_append_datal2tp_ip6_sendmsg needs to avoid accounting for the transport headertwice when splicing more data into an already partially-occupied skbuff.To manage this, we check whether the skbuff contains data usingskb_queue_empty when deciding how much data to append usingip6_append_data.However, the code which performed the calculation was incorrect:     ulen = len + skb_queue_empty(&amp;sk-&gt;sk_write_queue) ? transhdrlen : 0;...due to C operator precedence, this ends up setting ulen totranshdrlen for messages with a non-zero length, which results incorrupted packets on the wire.Add parentheses to correct the calculation in line with the originalintent.(CVE-2024-26752)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.74.0.154.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.74.0.154.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.74.0.154.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1576</id>
          <title>An update for kubernetes is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3177" id="CVE-2024-3177" title="CVE-2024-3177" type="cve"></reference>
          </references>
          <description>A security issue was discovered in Kubernetes where users may be able to launch containers that bypass the mountable secrets policy enforced by the ServiceAccount admission plugin when using containers, init containers, and ephemeral containers with the envFrom field populated. The policy ensures pods running with a service account may only reference secrets specified in the service account’s secrets field. Kubernetes clusters are only affected if the ServiceAccount admission plugin and the kubernetes.io/enforce-mountable-secrets annotation are used together with containers, init containers, and ephemeral containers with the envFrom field populated.(CVE-2024-3177)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kubernetes-kubelet" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubelet-1.20.2-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-master" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-master-1.20.2-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-node" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-node-1.20.2-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-1.20.2-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-kubeadm" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubeadm-1.20.2-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-client" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-client-1.20.2-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kubernetes-help" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-help-1.20.2-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-node" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-node-1.20.2-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-kubelet" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubelet-1.20.2-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-1.20.2-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-help" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-help-1.20.2-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-kubeadm" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-kubeadm-1.20.2-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-client" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-client-1.20.2-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kubernetes-master" release="21.oe2203sp1" version="1.20.2">
                         <filename>kubernetes-master-1.20.2-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1581</id>
          <title>An update for skopeo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-41723" id="CVE-2022-41723" title="CVE-2022-41723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29406" id="CVE-2023-29406" title="CVE-2023-29406" type="cve"></reference>
          </references>
          <description>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-41723)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.(CVE-2023-29406)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="skopeo" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="containers-common" release="7.oe2203sp1" version="1.5.2">
                         <filename>containers-common-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="skopeo-debugsource" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debugsource-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="skopeo-debuginfo" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debuginfo-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="containers-common" release="7.oe2203sp1" version="1.5.2">
                         <filename>containers-common-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo-debuginfo" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debuginfo-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo-debugsource" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debugsource-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1585</id>
          <title>An update for OpenEXR is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31047" id="CVE-2024-31047" title="CVE-2024-31047" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-31047)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="OpenEXR" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-3.1.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenEXR-debugsource" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-debugsource-3.1.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenEXR-devel" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-devel-3.1.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenEXR-debuginfo" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-debuginfo-3.1.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenEXR-libs" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-libs-3.1.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR-libs" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-libs-3.1.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR-debugsource" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-debugsource-3.1.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR-devel" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-devel-3.1.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR-debuginfo" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-debuginfo-3.1.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenEXR" release="3.oe2203sp1" version="3.1.5">
                         <filename>OpenEXR-3.1.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1587</id>
          <title>An update for less is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32487" id="CVE-2024-32487" title="CVE-2024-32487" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-32487)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="less-debugsource" release="6.oe2203sp1" version="590">
                         <filename>less-debugsource-590-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="less" release="6.oe2203sp1" version="590">
                         <filename>less-590-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="less-debuginfo" release="6.oe2203sp1" version="590">
                         <filename>less-debuginfo-590-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="less-help" release="6.oe2203sp1" version="590">
                         <filename>less-help-590-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less-debuginfo" release="6.oe2203sp1" version="590">
                         <filename>less-debuginfo-590-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less" release="6.oe2203sp1" version="590">
                         <filename>less-590-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="less-debugsource" release="6.oe2203sp1" version="590">
                         <filename>less-debugsource-590-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1590</id>
          <title>An update for sane-backends is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46047" id="CVE-2023-46047" title="CVE-2023-46047" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46052" id="CVE-2023-46052" title="CVE-2023-46052" type="cve"></reference>
          </references>
          <description>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-46047)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.(CVE-2023-46052)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="sane-backends-debuginfo" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-debuginfo-1.0.28-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sane-backends-devel" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-devel-1.0.28-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sane-backends-daemon" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-daemon-1.0.28-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sane-backends-drivers-cameras" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-drivers-cameras-1.0.28-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sane-backends" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-1.0.28-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sane-backends-drivers-scanners" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-drivers-scanners-1.0.28-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sane-backends-debugsource" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-debugsource-1.0.28-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="sane-backends-libs" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-libs-1.0.28-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="sane-backends-help" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-help-1.0.28-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sane-backends" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-1.0.28-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sane-backends-daemon" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-daemon-1.0.28-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sane-backends-libs" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-libs-1.0.28-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sane-backends-drivers-scanners" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-drivers-scanners-1.0.28-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sane-backends-drivers-cameras" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-drivers-cameras-1.0.28-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sane-backends-debuginfo" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-debuginfo-1.0.28-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sane-backends-devel" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-devel-1.0.28-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="sane-backends-debugsource" release="12.oe2203sp1" version="1.0.28">
                         <filename>sane-backends-debugsource-1.0.28-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1591</id>
          <title>An update for docker is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32473" id="CVE-2024-32473" title="CVE-2024-32473" type="cve"></reference>
          </references>
          <description>Moby is an open source container framework that is a key component of Docker Engine, Docker Desktop, and other distributions of container tooling or runtimes. In 26.0.0, IPv6 is not disabled on network interfaces, including those belonging to networks where `--ipv6=false`. An container with an `ipvlan` or `macvlan` interface will normally be configured to share an external network link with the host machine. Because of this direct access, (1) Containers may be able to communicate with other hosts on the local network over link-local IPv6 addresses, (2) if router advertisements are being broadcast over the local network, containers may get SLAAC-assigned addresses, and (3) the interface  will be a member of IPv6 multicast groups. This means interfaces in IPv4-only networks present an unexpectedly and unnecessarily increased attack surface. The issue is patched in 26.0.2. To completely disable IPv6 in a container, use `--sysctl=net.ipv6.conf.all.disable_ipv6=1` in the `docker create` or `docker run` command. Or, in the service configuration of a `compose` file.(CVE-2024-32473)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="docker-engine-debuginfo" release="335.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-335.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine" release="335.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-335.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="docker-engine-debugsource" release="335.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-335.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debugsource" release="335.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-335.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine" release="335.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-335.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="docker-engine-debuginfo" release="335.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-335.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1592</id>
          <title>An update for php is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3096" id="CVE-2024-3096" title="CVE-2024-3096" type="cve"></reference>
          </references>
          <description>In PHP  version 8.1.* before 8.1.28, 8.2.* before 8.2.18, 8.3.* before 8.3.5, 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.(CVE-2024-3096)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="php-gd" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-soap" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-enchant" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-xml" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-help" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-help" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="3.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1594</id>
          <title>An update for glibc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33599" id="CVE-2024-33599" title="CVE-2024-33599" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33600" id="CVE-2024-33600" title="CVE-2024-33600" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33601" id="CVE-2024-33601" title="CVE-2024-33601" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33602" id="CVE-2024-33602" title="CVE-2024-33602" type="cve"></reference>
          </references>
          <description>nscd: Stack-based buffer overflow in netgroup cacheIf the Name Service Cache Daemon&#39;s (nscd) fixed size cache is exhaustedby client requests then a subsequent client request for netgroup datamay result in a stack-based buffer overflow.  This flaw was introducedin glibc 2.15 when the cache was added to nscd.This vulnerability is only present in the nscd binary.(CVE-2024-33599)nscd: Null pointer crashes after notfound responseIf the Name Service Cache Daemon&#39;s (nscd) cache fails to add a not-foundnetgroup response to the cache, the client request can result in a nullpointer dereference.  This flaw was introduced in glibc 2.15 when thecache was added to nscd.This vulnerability is only present in the nscd binary.(CVE-2024-33600)nscd: netgroup cache may terminate daemon on memory allocation failureThe Name Service Cache Daemon&#39;s (nscd) netgroup cache uses xmalloc orxrealloc and these functions may terminate the process due to a memoryallocation failure resulting in a denial of service to the clients.  Theflaw 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 assumes NSS callback uses in-buffer stringsThe Name Service Cache Daemon&#39;s (nscd) netgroup cache can corrupt memorywhen 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.(CVE-2024-33602)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nss_modules" release="150.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-compat-2.17" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-devel" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-all-langpacks" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-archive" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugsource" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-common" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-nss-devel" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnsl" release="150.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debuginfo" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugutils" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nscd" release="150.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-source" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glibc-help" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-help-2.34-150.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-all-langpacks" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-common" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-source" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-nss-devel" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugsource" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-archive" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnsl" release="150.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nscd" release="150.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss_modules" release="150.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugutils" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debuginfo" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-compat-2.17" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-devel" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1600</id>
          <title>An update for xorg-x11-server-xwayland is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0229" id="CVE-2024-0229" title="CVE-2024-0229" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0409" id="CVE-2024-0409" title="CVE-2024-0409" type="cve"></reference>
          </references>
          <description>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-2024-0229)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-2024-0409)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-devel" release="5.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland" release="5.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debugsource" release="5.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debuginfo" release="5.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debuginfo" release="5.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-devel" release="5.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland" release="5.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debugsource" release="5.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1601</id>
          <title>An update for youker-assistant is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-2091" id="CVE-2023-2091" title="CVE-2023-2091" type="cve"></reference>
          </references>
          <description>A vulnerability classified as critical was found in KylinSoft youker-assistant on KylinOS. Affected by this vulnerability is the function adjust_cpufreq_scaling_governer. The manipulation leads to os command injection. It is possible to launch the attack on the local host. The exploit has been disclosed to the public and may be used. Upgrading to version 3.1.4.13 is able to address this issue. It is recommended to upgrade the affected component. The associated identifier of this vulnerability is VDB-226099.(CVE-2023-2091)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="youker-assistant-debugsource" release="8.oe2203sp1" version="3.0.3">
                         <filename>youker-assistant-debugsource-3.0.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="youker-assistant" release="8.oe2203sp1" version="3.0.3">
                         <filename>youker-assistant-3.0.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="youker-assistant-debuginfo" release="8.oe2203sp1" version="3.0.3">
                         <filename>youker-assistant-debuginfo-3.0.3-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="youker-assistant-debugsource" release="8.oe2203sp1" version="3.0.3">
                         <filename>youker-assistant-debugsource-3.0.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="youker-assistant" release="8.oe2203sp1" version="3.0.3">
                         <filename>youker-assistant-3.0.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="youker-assistant-debuginfo" release="8.oe2203sp1" version="3.0.3">
                         <filename>youker-assistant-debuginfo-3.0.3-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1604</id>
          <title>An update for iperf3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26306" id="CVE-2024-26306" title="CVE-2024-26306" type="cve"></reference>
          </references>
          <description>iPerf3 before 3.17, when used with OpenSSL before 3.2.0 as a server with RSA authentication, allows a timing side channel in RSA decryption operations. This side channel could be sufficient for an attacker to recover credential plaintext. It requires the attacker to send a large number of messages for decryption, as described in &#34;Everlasting ROBOT: the Marvin Attack&#34; by Hubert Kario.(CVE-2024-26306)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="iperf3-debuginfo" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-debuginfo-3.16-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-debugsource" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-debugsource-3.16-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3-devel" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-devel-3.16-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="iperf3" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-3.16-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="iperf3-help" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-help-3.16-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-3.16-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-devel" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-devel-3.16-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-debugsource" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-debugsource-3.16-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="iperf3-debuginfo" release="3.oe2203sp1" version="3.16">
                         <filename>iperf3-debuginfo-3.16-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1605</id>
          <title>An update for python-jinja2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34064" id="CVE-2024-34064" title="CVE-2024-34064" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-34064)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-jinja2" release="4.oe2203sp1" version="3.0.3">
                         <filename>python3-jinja2-3.0.3-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-jinja2-help" release="4.oe2203sp1" version="3.0.3">
                         <filename>python-jinja2-help-3.0.3-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1606</id>
          <title>An update for python-idna is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3651" id="CVE-2024-3651" title="CVE-2024-3651" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-3651)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-idna" release="3.oe2203sp1" version="3.2">
                         <filename>python3-idna-3.2-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1610</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27282" id="CVE-2024-27282" title="CVE-2024-27282" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-27282)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="rubygem-psych" release="133.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="133.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="133.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="133.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="133.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-133.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="133.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="133.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="133.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="133.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="133.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="133.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="133.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="133.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="133.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="133.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="133.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="133.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-133.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="133.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="133.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="133.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="133.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="133.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="133.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-133.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1614</id>
          <title>An update for qt5-qtbase is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45935" id="CVE-2023-45935" title="CVE-2023-45935" type="cve"></reference>
          </references>
          <description>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-2023-45935)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qt5-qtbase-debuginfo" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-mysql" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-gui" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-devel" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-private-devel" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-debugsource" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-postgresql" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-odbc" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-static" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qt5-qtbase-examples" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-16.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qt5-qtbase-common" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-common-5.15.2-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-static" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-static-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-examples" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-examples-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-private-devel" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-private-devel-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-gui" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-gui-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-postgresql" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-postgresql-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debuginfo" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debuginfo-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-debugsource" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-debugsource-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-mysql" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-mysql-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-odbc" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-odbc-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qt5-qtbase-devel" release="16.oe2203sp1" version="5.15.2">
                         <filename>qt5-qtbase-devel-5.15.2-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1620</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-17"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48655" id="CVE-2022-48655" title="CVE-2022-48655" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52477" id="CVE-2023-52477" title="CVE-2023-52477" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52618" id="CVE-2023-52618" title="CVE-2023-52618" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52620" id="CVE-2023-52620" title="CVE-2023-52620" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52628" id="CVE-2023-52628" title="CVE-2023-52628" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52642" id="CVE-2023-52642" title="CVE-2023-52642" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6270" id="CVE-2023-6270" title="CVE-2023-6270" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26668" id="CVE-2024-26668" title="CVE-2024-26668" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26669" id="CVE-2024-26669" title="CVE-2024-26669" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26671" id="CVE-2024-26671" title="CVE-2024-26671" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26680" id="CVE-2024-26680" title="CVE-2024-26680" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26688" id="CVE-2024-26688" title="CVE-2024-26688" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26689" id="CVE-2024-26689" title="CVE-2024-26689" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26791" id="CVE-2024-26791" title="CVE-2024-26791" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26792" id="CVE-2024-26792" title="CVE-2024-26792" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26811" id="CVE-2024-26811" title="CVE-2024-26811" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26812" id="CVE-2024-26812" title="CVE-2024-26812" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26817" id="CVE-2024-26817" title="CVE-2024-26817" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26828" id="CVE-2024-26828" title="CVE-2024-26828" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26839" id="CVE-2024-26839" title="CVE-2024-26839" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26840" id="CVE-2024-26840" title="CVE-2024-26840" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26843" id="CVE-2024-26843" title="CVE-2024-26843" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26855" id="CVE-2024-26855" title="CVE-2024-26855" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26870" id="CVE-2024-26870" title="CVE-2024-26870" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26875" id="CVE-2024-26875" title="CVE-2024-26875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26878" id="CVE-2024-26878" title="CVE-2024-26878" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26893" id="CVE-2024-26893" title="CVE-2024-26893" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26898" id="CVE-2024-26898" title="CVE-2024-26898" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Harden accesses to the reset domainsAccessing reset domains descriptors by the index upon the SCMI driversrequests through the SCMI reset operations interface can potentiallylead to out-of-bound violations if the SCMI driver misbehave.Add an internal consistency check before any such domains descriptorsaccesses.(CVE-2022-48655)In the Linux kernel, the following vulnerability has been resolved:usb: hub: Guard against accesses to uninitialized BOS descriptorsMany functions in drivers/usb/core/hub.c and drivers/usb/core/hub.haccess fields inside udev-&gt;bos without checking if it was allocated andinitialized. If usb_get_bos_descriptor() fails for whateverreason, udev-&gt;bos will be NULL and those accesses will result in acrash:BUG: kernel NULL pointer dereference, address: 0000000000000018PGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 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/2021Workqueue: usb_hub_wq hub_eventRIP: 0010:hub_port_reset+0x193/0x788Code: 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 e9RSP: 0018:ffffab740c53fcf8 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffffa1bc5f678000 RCX: 0000000000000310RDX: fffffffffffffdff RSI: 0000000000000286 RDI: ffffa1be9655b840RBP: ffffab740c53fd70 R08: 00001b7d5edaa20c R09: ffffffffb005e060R10: 0000000000000001 R11: 0000000000000000 R12: 0000000000000000R13: ffffab740c53fd3e R14: 0000000000000032 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffffa1be96540000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000018 CR3: 000000022e80c005 CR4: 00000000003706e0Call Trace:hub_event+0x73f/0x156e? hub_activate+0x5b7/0x68fprocess_one_work+0x1a2/0x487worker_thread+0x11a/0x288kthread+0x13a/0x152? process_one_work+0x487/0x487? kthread_associate_blkcg+0x70/0x70ret_from_fork+0x1f/0x30Fall back to a default behavior if the BOS descriptor isn&#39;t accessibleand skip all the functionalities that depend on it: LPM support checks,Super Speed capabilitiy checks, U1/U2 states setup.(CVE-2023-52477)In the Linux kernel, the following vulnerability has been resolved:block/rnbd-srv: Check for unlikely string overflowSince &#34;dev_search_path&#34; can technically be as large as PATH_MAX,there was a risk of truncation when copying it and a second stringinto &#34;full_path&#34; since it was also PATH_MAX sized. The W=1 builds werereporting this warning:drivers/block/rnbd/rnbd-srv.c: In function &#39;process_msg_open.isra&#39;:drivers/block/rnbd/rnbd-srv.c:616:51: warning: &#39;%s&#39; directive output may be truncated writing up to 254 bytes into a region of size between 0 and 4095 [-Wformat-truncation=]  616 |                 snprintf(full_path, PATH_MAX, &#34;%s/%s&#34;,      |                                                   ^~In function &#39;rnbd_srv_get_full_path&#39;,    inlined from &#39;process_msg_open.isra&#39; at drivers/block/rnbd/rnbd-srv.c:721:14: drivers/block/rnbd/rnbd-srv.c:616:17: note: &#39;snprintf&#39; output between 2 and 4351 bytes into a destination of size 4096  616 |                 snprintf(full_path, PATH_MAX, &#34;%s/%s&#34;,      |                 ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  617 |                          dev_search_path, dev_name);      |                          ~~~~~~~~~~~~~~~~~~~~~~~~~~To fix this, unconditionally check for truncation (as was already donefor the case where &#34;%SESSNAME%&#34; was present).(CVE-2023-52618)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: disallow timeout for anonymous setsNever used from userspace, disallow these parameters.(CVE-2023-52620)In the Linux kernel, the following vulnerability has been resolved:netfilter: nftables: exthdr: fix 4-byte stack OOB writeIf priv-&gt;len is a multiple of 4, then dst[len / 4] can write pastthe destination array which leads to stack corruption.This construct is necessary to clean the remainder of the registerin case -&gt;len is NOT a multiple of the register size, so make itconditional just like nft_payload.c does.The bug was added in 4.1 cycle and then copied/inherited whentcp/sctp and ip option support was added.Bug reported by Zero Day Initiative project (ZDI-CAN-21950,ZDI-CAN-21951, ZDI-CAN-21961).(CVE-2023-52628)In the Linux kernel, the following vulnerability has been resolved:media: rc: bpf attach/detach requires write permissionNote that bpf attach/detach also requires CAP_NET_ADMIN.(CVE-2023-52642)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-2023-6270)In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_limit: reject configurations that cause integer overflowReject 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-2024-26668)In the Linux kernel, the following vulnerability has been resolved:net/sched: flower: Fix chain template offloadWhen a qdisc is deleted from a net device the stack instructs theunderlying driver to remove its flow offload callback from theassociated filter block using the &#39;FLOW_BLOCK_UNBIND&#39; command. The stackthen continues to replay the removal of the filters in the block forthis driver by iterating over the chains in the block and invoking the&#39;reoffload&#39; operation of the classifier being used. In turn, theclassifier in its &#39;reoffload&#39; operation prepares and emits a&#39;FLOW_CLS_DESTROY&#39; command for each filter.However, the stack does not do the same for chain templates and theunderlying driver never receives a &#39;FLOW_CLS_TMPLT_DESTROY&#39; command whena qdisc is deleted. This results in a memory leak [1] which can bereproduced using [2].Fix by introducing a &#39;tmplt_reoffload&#39; operation and have the stackinvoke it with the appropriate arguments as part of the replay.Implement the operation in the sole classifier that supports chaintemplates (flower) by emitting the &#39;FLOW_CLS_TMPLT_{CREATE,DESTROY}&#39;command based on whether a flow offload callback is being bound to afilter block or being unbound from one.As far as I can tell, the issue happens since cited commit whichreordered tcf_block_offload_unbind() before tcf_block_flush_all_chains()in __tcf_block_put(). The order cannot be reversed as the filter blockis expected to be freed after flushing all the chains.[1]unreferenced object 0xffff888107e28800 (size 2048):  comm &#34;tc&#34;, 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/0xe0unreferenced object 0xffff88816d2c0400 (size 1024):  comm &#34;tc&#34;, 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-26669)In the Linux kernel, the following vulnerability has been resolved:blk-mq: fix IO hang from sbitmap wakeup raceIn blk_mq_mark_tag_wait(), __add_wait_queue() may be re-orderedwith the following blk_mq_get_driver_tag() in case of getting drivertag failure.Then in __sbitmap_queue_wake_up(), waitqueue_active() may not observethe added waiter in blk_mq_mark_tag_wait() and wake up nothing, meantimeblk_mq_mark_tag_wait() can&#39;t get driver tag successfully.This issue can be reproduced by running the following test in loop, andfio hang can be observed in &lt; 30min when running it on my test VMin laptop.&#x9;modprobe -r scsi_debug&#x9;modprobe scsi_debug delay=0 dev_size_mb=4096 max_queue=1 host_max_queue=1 submit_queues=4&#x9;dev=`ls -d /sys/bus/pseudo/drivers/scsi_debug/adapter*/host*/target*/*/block/* | head -1 | xargs basename`&#x9;fio --filename=/dev/&#34;$dev&#34; --direct=1 --rw=randrw --bs=4k --iodepth=1 \       &#x9;&#x9;--runtime=100 --numjobs=40 --time_based --name=test \        &#x9;--ioengine=libaioFix the issue by adding one explicit barrier in blk_mq_mark_tag_wait(), whichis just fine in case of running out of tag.(CVE-2024-26671)In the Linux kernel, the following vulnerability has been resolved:net: atlantic: Fix DMA mapping for PTP hwts ringFunction aq_ring_hwts_rx_alloc() maps extra AQ_CFG_RXDS_DEF bytesfor PTP HWTS ring but then generic aq_ring_free() does not take thisinto account.Create and use a specific function to free HWTS ring to fix thisissue.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-26680)In the Linux kernel, the following vulnerability has been resolved:fs,hugetlb: fix NULL pointer dereference in hugetlbs_fill_superWhen configuring a hugetlb filesystem via the fsconfig() syscall, there isa possible NULL dereference in hugetlbfs_fill_super() caused by assigningNULL to ctx-&gt;hstate in hugetlbfs_parse_param() when the requested pagesizeis non valid.E.g: Taking the following steps:     fd = fsopen(&#34;hugetlbfs&#34;, FSOPEN_CLOEXEC);     fsconfig(fd, FSCONFIG_SET_STRING, &#34;pagesize&#34;, &#34;1024&#34;, 0);     fsconfig(fd, FSCONFIG_CMD_CREATE, NULL, NULL, 0);Given that the requested &#34;pagesize&#34; is invalid, ctxt-&gt;hstate will be replacedwith NULL, losing its previous value, and we will print an error: ... ... case Opt_pagesize: ps = memparse(param-&gt;string, &amp;rest); ctx-&gt;hstate = h; if (!ctx-&gt;hstate) {         pr_err(&#34;Unsupported page size %lu MB\n&#34;, ps / SZ_1M);         return -EINVAL; } return 0; ... ...This is a problem because later on, we will dereference ctxt-&gt;hstate inhugetlbfs_fill_super() ... ... sb-&gt;s_blocksize = huge_page_size(ctx-&gt;hstate); ... ...Causing below Oops.Fix this by replacing cxt-&gt;hstate value only when then pagesize is knownto be valid. kernel: hugetlbfs: Unsupported page size 0 MB kernel: BUG: kernel NULL pointer dereference, address: 0000000000000028 kernel: #PF: supervisor read access in kernel mode kernel: #PF: error_code(0x0000) - not-present page kernel: PGD 800000010f66c067 P4D 800000010f66c067 PUD 1b22f8067 PMD 0 kernel: Oops: 0000 [#1] PREEMPT SMP PTI kernel: CPU: 4 PID: 5659 Comm: syscall Tainted: G            E      6.8.0-rc2-default+ #22 5a47c3fef76212addcc6eb71344aabc35190ae8f kernel: Hardware name: Intel Corp. GROVEPORT/GROVEPORT, BIOS GVPRCRB1.86B.0016.D04.1705030402 05/03/2017 kernel: RIP: 0010:hugetlbfs_fill_super+0xb4/0x1a0 kernel: Code: 48 8b 3b e8 3e c6 ed ff 48 85 c0 48 89 45 20 0f 84 d6 00 00 00 48 b8 ff ff ff ff ff ff ff 7f 4c 89 e7 49 89 44 24 20 48 8b 03 &lt;8b&gt; 48 28 b8 00 10 00 00 48 d3 e0 49 89 44 24 18 48 8b 03 8b 40 28 kernel: RSP: 0018:ffffbe9960fcbd48 EFLAGS: 00010246 kernel: RAX: 0000000000000000 RBX: ffff9af5272ae780 RCX: 0000000000372004 kernel: RDX: ffffffffffffffff RSI: ffffffffffffffff RDI: ffff9af555e9b000 kernel: RBP: ffff9af52ee66b00 R08: 0000000000000040 R09: 0000000000370004 kernel: R10: ffffbe9960fcbd48 R11: 0000000000000040 R12: ffff9af555e9b000 kernel: R13: ffffffffa66b86c0 R14: ffff9af507d2f400 R15: ffff9af507d2f400 kernel: FS:  00007ffbc0ba4740(0000) GS:ffff9b0bd7000000(0000) knlGS:0000000000000000 kernel: CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033 kernel: CR2: 0000000000000028 CR3: 00000001b1ee0000 CR4: 00000000001506f0 kernel: Call Trace: kernel:  &lt;TASK&gt; kernel:  ? __die_body+0x1a/0x60 kernel:  ? page_fault_oops+0x16f/0x4a0 kernel:  ? search_bpf_extables+0x65/0x70 kernel:  ? fixup_exception+0x22/0x310 kernel:  ? exc_page_fault+0x69/0x150 kernel:  ? asm_exc_page_fault+0x22/0x30 kernel:  ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel:  ? hugetlbfs_fill_super+0xb4/0x1a0 kernel:  ? hugetlbfs_fill_super+0x28/0x1a0 kernel:  ? __pfx_hugetlbfs_fill_super+0x10/0x10 kernel:  vfs_get_super+0x40/0xa0 kernel:  ? __pfx_bpf_lsm_capable+0x10/0x10 kernel:  vfs_get_tree+0x25/0xd0 kernel:  vfs_cmd_create+0x64/0xe0 kernel:  __x64_sys_fsconfig+0x395/0x410 kernel:  do_syscall_64+0x80/0x160 kernel:  ? syscall_exit_to_user_mode+0x82/0x240 kernel:  ? do_syscall_64+0x8d/0x160 kernel:  ? syscall_exit_to_user_mode+0x82/0x240 kernel:  ? do_syscall_64+0x8d/0x160 kernel:  ? exc_page_fault+0x69/0x150 kernel:  entry_SYSCALL_64_after_hwframe+0x6e/0x76 kernel: RIP: 0033:0x7ffbc0cb87c9 kernel: Code: 00 90 90 90 90 90 90 90 90 90 90 90 90 90 90 66 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 96 0d 00 f7 d8 64 89 01 48 kernel: RSP: 002b:00007ffc29d2f388 EFLAGS: 00000206 ORIG_RAX: 00000000000001af kernel: RAX: fffffffffff---truncated---(CVE-2024-26688)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(), &#34;use after free&#34; error wascaught by KASAN at this line - &#39;ceph_buffer_get(arg-&gt;xattr_buf);&#39;. Thisimplies before the refcount could be increment here, it was freed.In same file, in &#34;handle_cap_grant()&#34; refcount is decremented by thisline - &#39;ceph_buffer_put(ci-&gt;i_xattrs.blob);&#39;. It appears that a raceoccurred and resource was freed by the latter line before the formerline could increment it.encode_cap_msg() is called by __send_cap() and __send_cap() is called byceph_check_caps() after calling __prep_cap(). __prep_cap() is wherearg-&gt;xattr_buf is assigned to ci-&gt;i_xattrs.blob. This is the spot wherethe refcount must be increased to prevent &#34;use after free&#34; error.(CVE-2024-26689)In the Linux kernel, the following vulnerability has been resolved:btrfs: dev-replace: properly validate device namesThere&#39;s a syzbot report that device name buffers passed to devicereplace are not properly checked for string termination which could leadto 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 casesomething tries to read it later.This was originally analyzed and fixed in a different way by Edward AdamDavis (see links).(CVE-2024-26791)In the Linux kernel, the following vulnerability has been resolved:btrfs: fix double free of anonymous device after snapshot creation failureWhen creating a snapshot we may do a double free of an anonymous devicein case there&#39;s an error committing the transaction. The second free mayresult in freeing an anonymous device number that was allocated by someother subsystem in the kernel or another btrfs filesystem.The steps that lead to this:1) At ioctl.c:create_snapshot() we allocate an anonymous device number   and assign it to pending_snapshot-&gt;anon_dev;2) Then we call btrfs_commit_transaction() and end up at   transaction.c:create_pending_snapshot();3) There we call btrfs_get_new_fs_root() and pass it the anonymous device   number stored in pending_snapshot-&gt;anon_dev;4) btrfs_get_new_fs_root() frees that anonymous device number because   btrfs_lookup_fs_root() returned a root - someone else did a lookup   of the new root already, which could some task doing backref walking;5) After that some error happens in the transaction commit path, and at   ioctl.c:create_snapshot() we jump to the &#39;fail&#39; label, and after   that we free again the same anonymous device number, which in the   meanwhile may have been reallocated somewhere else, because   pending_snapshot-&gt;anon_dev still has the same value as in step 1.Recently syzbot ran into this and reported the following trace:  ------------[ cut here ]------------  ida_free called for id=51 which is not allocated.  WARNING: CPU: 1 PID: 31038 at lib/idr.c:525 ida_free+0x370/0x420 lib/idr.c:525  Modules linked in:  CPU: 1 PID: 31038 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-00410-gc02197fc9076 #0  Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024  RIP: 0010:ida_free+0x370/0x420 lib/idr.c:525  Code: 10 42 80 3c 28 (...)  RSP: 0018:ffffc90015a67300 EFLAGS: 00010246  RAX: be5130472f5dd000 RBX: 0000000000000033 RCX: 0000000000040000  RDX: ffffc90009a7a000 RSI: 000000000003ffff RDI: 0000000000040000  RBP: ffffc90015a673f0 R08: ffffffff81577992 R09: 1ffff92002b4cdb4  R10: dffffc0000000000 R11: fffff52002b4cdb5 R12: 0000000000000246  R13: dffffc0000000000 R14: ffffffff8e256b80 R15: 0000000000000246  FS:  00007fca3f4b46c0(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000  CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033  CR2: 00007f167a17b978 CR3: 000000001ed26000 CR4: 0000000000350ef0  Call Trace:   &lt;TASK&gt;   btrfs_get_root_ref+0xa48/0xaf0 fs/btrfs/disk-io.c:1346   create_pending_snapshot+0xff2/0x2bc0 fs/btrfs/transaction.c:1837   create_pending_snapshots+0x195/0x1d0 fs/btrfs/transaction.c:1931   btrfs_commit_transaction+0xf1c/0x3740 fs/btrfs/transaction.c:2404   create_snapshot+0x507/0x880 fs/btrfs/ioctl.c:848   btrfs_mksubvol+0x5d0/0x750 fs/btrfs/ioctl.c:998   btrfs_mksnapshot+0xb5/0xf0 fs/btrfs/ioctl.c:1044   __btrfs_ioctl_snap_create+0x387/0x4b0 fs/btrfs/ioctl.c:1306   btrfs_ioctl_snap_create_v2+0x1ca/0x400 fs/btrfs/ioctl.c:1393   btrfs_ioctl+0xa74/0xd40   vfs_ioctl fs/ioctl.c:51 [inline]   __do_sys_ioctl fs/ioctl.c:871 [inline]   __se_sys_ioctl+0xfe/0x170 fs/ioctl.c:857   do_syscall_64+0xfb/0x240   entry_SYSCALL_64_after_hwframe+0x6f/0x77  RIP: 0033:0x7fca3e67dda9  Code: 28 00 00 00 (...)  RSP: 002b:00007fca3f4b40c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010  RAX: ffffffffffffffda RBX: 00007fca3e7abf80 RCX: 00007fca3e67dda9  RDX: 00000000200005c0 RSI: 0000000050009417 RDI: 0000000000000003  RBP: 00007fca3e6ca47a R08: 0000000000000000 R09: 0000000000000000  R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000  R13: 000000000000000b R14: 00007fca3e7abf80 R15: 00007fff6bf95658   &lt;/TASK&gt;Where we get an explicit message where we attempt to free an anonymousdevice number that is not currently allocated. It happens in a differentcode path from the example below, at btrfs_get_root_ref(), so this changemay not fix the case triggered by sy---truncated---(CVE-2024-26792)In the Linux kernel, the following vulnerability has been resolved:ksmbd: validate payload size in ipc responseIf installing malicious ksmbd-tools, ksmbd.mountd can return invalid ipcresponse to ksmbd kernel server. ksmbd should validate payload size ofipc response from ksmbd.mountd to avoid memory overrun orslab-out-of-bounds. This patch validate 3 ipc response that has payload.(CVE-2024-26811)In the Linux kernel, the following vulnerability has been resolved:vfio/pci: Create persistent INTx handlerA vulnerability exists where the eventfd for INTx signaling can bedeconfigured, which unregisters the IRQ handler but still allowseventfds to be signaled with a NULL context through the SET_IRQS ioctlor through unmask irqfd if the device interrupt is pending.Ideally this could be solved with some additional locking; the igatemutex serializes the ioctl and config space accesses, and the interrupthandler is unregistered relative to the trigger, but the irqfd pathruns asynchronous to those.  The igate mutex cannot be acquired from theatomic context of the eventfd wake function.  Disabling the irqfdrelative to the eventfd registration is potentially incompatible withexisting userspace.As a result, the solution implemented here moves configuration of theINTx interrupt handler to track the lifetime of the INTx context objectand irq_type configuration, rather than registration of a particulartrigger eventfd.  Synchronization is added between the ioctl path andeventfd_signal() wrapper such that the eventfd trigger can bedynamically updated relative to in-flight interrupts or irqfd callbacks.(CVE-2024-26812)In the Linux kernel, the following vulnerability has been resolved:amdkfd: use calloc instead of kzalloc to avoid integer overflowThis uses calloc instead of doing the multiplication which mightoverflow.(CVE-2024-26817)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 checkif the size_left is greater than the minimum size we need.  However,the problem is that &#34;bytes_left&#34; is type ssize_t while sizeof() is typesize_t.  That means that because of type promotion, the comparison isdone as an unsigned and if we have negative bytes left the loopcontinues instead of ending.(CVE-2024-26828)In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Fix a memleak in init_credit_returnWhen dma_alloc_coherent fails to allocate dd-&gt;cr_base[i].va,init_credit_return should deallocate dd-&gt;cr_base anddd-&gt;cr_base[i] that allocated before. Or those resourceswould be never freed and a memleak is triggered.(CVE-2024-26839)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 &#34;cachefilesd2&#34;, 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() tofix the problem. And also put cache_cred in cachefiles_add_cache() errorbranch to avoid memory leaks.(CVE-2024-26840)In the Linux kernel, the following vulnerability has been resolved:efi: runtime: Fix potential overflow of soft-reserved region sizemd_size will have been narrowed if we have &gt;= 4GB worth of pages in asoft-reserved region.(CVE-2024-26843)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 dereferenceif nlmsg_find_attr() returns NULL and br_spec is dereferenced subsequentlyin nla_for_each_nested(). To address this issue, add a check to ensure thatbr_spec is not NULL before proceeding with the nested attribute iteration.(CVE-2024-26855)In the Linux kernel, the following vulnerability has been resolved:NFSv4.2: fix nfs4_listxattr kernel BUG at mm/usercopy.c:102A call to listxattr() with a buffer size = 0 returns the actualsize of the buffer needed for a subsequent call. When size &gt; 0,nfs4_listxattr() does not return an error because eithergeneric_listxattr() or nfs4_listxattr_nfs4_label() consumesexactly all the bytes then size is 0 when callingnfs4_listxattr_nfs4_user() which then triggers the followingkernel 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 &#39;system.nfs4_acl&#39;,thus calling lisxattr() with size = 16 will trigger the bug.Add check on nfs4_listxattr() to return ERANGE error when it iscalled with size &gt; 0 and the return value is greater than size.(CVE-2024-26870)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:35Read of size 4 at addr ffff888113aeb0d8 by task kworker/1:1/26CPU: 1 PID: 26 Comm: kworker/1:1 Not tainted 6.8.0-rc1-syzkaller-00046-gf1a27f081c1f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Workqueue: usb_hub_wq hub_eventCall 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:272Freed by task 906:kasan_save_stack+0x33/0x50 mm/kasan/common.c:47kasan_save_track+0x14/0x30 mm/kasan/common.c:68kasan_save_free_info+0x3f/0x60 mm/kasan/generic.c:640poison_slab_object mm/kasan/common.c:241 [inline]__kasan_slab_free+0x106/0x1b0 mm/kasan/common.c:257kasan_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:4409pvr2_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&#39;s condition being metand 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-2024-26875)In the Linux kernel, the following vulnerability has been resolved:quota: Fix potential NULL pointer dereferenceBelow race may cause NULL pointer dereferenceP1&#x9;&#x9;&#x9;&#x9;&#x9;P2dquot_free_inode&#x9;&#x9;&#x9;quota_off&#x9;&#x9;&#x9;&#x9;&#x9;  drop_dquot_ref&#x9;&#x9;&#x9;&#x9;&#x9;   remove_dquot_ref&#x9;&#x9;&#x9;&#x9;&#x9;   dquots = i_dquot(inode)  dquots = i_dquot(inode)  srcu_read_lock  dquots[cnt]) != NULL (1)&#x9;&#x9;&#x9;&#x9;&#x9;     dquots[type] = NULL (2)  spin_lock(&amp;dquots[cnt]-&gt;dq_dqb_lock) (3)   ....If dquot_free_inode(or other routines) checks inode&#39;s quota pointers (1)before quota_off sets it to NULL(2) and use it (3) after that, NULL pointerdereference will be triggered.So let&#39;s fix it by using a temporary pointer to avoid this issue.(CVE-2024-26878)In the Linux kernel, the following vulnerability has been resolved:firmware: arm_scmi: Fix double free in SMC transport cleanup pathWhen the generic SCMI code tears down a channel, it calls the chan_freecallback function, defined by each transport. Since multiple protocolsmight share the same transport_info member, chan_free() might want toclean up the same member multiple times within the given SCMI transportimplementation. In this case, it is SMC transport. This will lead to a NULLpointer 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 accessits members, to avoid this situation.This was found when a transport doesn&#39;t really work (for instance no SMCservice), the probe routines then tries to clean up, and triggers a crash.(CVE-2024-26893)In the Linux kernel, the following vulnerability has been resolved:aoe: fix the potential use-after-free problem in aoecmd_cfg_pktsThis 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 initialcode is finished. But the net_device ifp will still be used inlater tx()-&gt;dev_queue_xmit() in kthread. Which means that thedev_put(ifp) should NOT be called in the success path of skbinitial code in aoecmd_cfg_pkts(). Otherwise tx() may run intouse-after-free because the net_device is freed.This patch removed the dev_put(ifp) in the success path inaoecmd_cfg_pkts(), and added dev_put() after skb xmit in tx().(CVE-2024-26898)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="perf" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.75.0.155.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.75.0.155.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.75.0.155.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1629</id>
          <title>An update for nautilus is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-37290" id="CVE-2022-37290" title="CVE-2022-37290" type="cve"></reference>
          </references>
          <description>GNOME Nautilus 42.2 allows a NULL pointer dereference and get_basename application crash via a pasted ZIP archive.(CVE-2022-37290)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nautilus-debugsource" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-debugsource-3.38.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nautilus" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-3.38.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nautilus-devel" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-devel-3.38.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nautilus-debuginfo" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-debuginfo-3.38.2-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="nautilus-help" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-help-3.38.2-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nautilus" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-3.38.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nautilus-devel" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-devel-3.38.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nautilus-debugsource" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-debugsource-3.38.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nautilus-debuginfo" release="2.oe2203sp1" version="3.38.2">
                         <filename>nautilus-debuginfo-3.38.2-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1634</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21087" id="CVE-2024-21087" title="CVE-2024-21087" type="cve"></reference>
          </references>
          <description>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-21087)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-server-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-debugsource-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-libs-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-errmsg-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-test-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-common-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-debuginfo-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-config-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-help-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-devel-8.0.37-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-debugsource-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-help-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-errmsg-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-libs-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-config-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-test-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-debuginfo-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-server-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-devel-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-common-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp1" version="8.0.37">
                         <filename>mysql-8.0.37-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1638</id>
          <title>An update for tpm2-tss is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29040" id="CVE-2024-29040" title="CVE-2024-29040" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-29040)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="tpm2-tss-debugsource" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-debugsource-3.1.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tpm2-tss-debuginfo" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-debuginfo-3.1.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tpm2-tss-devel" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-devel-3.1.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tpm2-tss" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-3.1.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="tpm2-tss-help" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-help-3.1.0-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tss-debugsource" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-debugsource-3.1.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tss-debuginfo" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-debuginfo-3.1.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tss-devel" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-devel-3.1.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tss" release="5.oe2203sp1" version="3.1.0">
                         <filename>tpm2-tss-3.1.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1641</id>
          <title>An update for libxml2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34459" id="CVE-2024-34459" title="CVE-2024-34459" type="cve"></reference>
          </references>
          <description>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-34459)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libxml2" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-2.9.14-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-libxml2" release="13.oe2203sp1" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debuginfo" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-debugsource" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libxml2-devel" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libxml2-help" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-help-2.9.14-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-libxml2" release="13.oe2203sp1" version="2.9.14">
                         <filename>python3-libxml2-2.9.14-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debuginfo" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debuginfo-2.9.14-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-debugsource" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-debugsource-2.9.14-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-2.9.14-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libxml2-devel" release="13.oe2203sp1" version="2.9.14">
                         <filename>libxml2-devel-2.9.14-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1644</id>
          <title>An update for skopeo is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28180" id="CVE-2024-28180" title="CVE-2024-28180" type="cve"></reference>
          </references>
          <description>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-2024-28180)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="skopeo-debugsource" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debugsource-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="skopeo" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="containers-common" release="7.oe2203sp1" version="1.5.2">
                         <filename>containers-common-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="skopeo-debuginfo" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debuginfo-1.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo-debugsource" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debugsource-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="containers-common" release="7.oe2203sp1" version="1.5.2">
                         <filename>containers-common-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="skopeo-debuginfo" release="7.oe2203sp1" version="1.5.2">
                         <filename>skopeo-debuginfo-1.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1648</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48659" id="CVE-2022-48659" title="CVE-2022-48659" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48660" id="CVE-2022-48660" title="CVE-2022-48660" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52609" id="CVE-2023-52609" title="CVE-2023-52609" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52615" id="CVE-2023-52615" title="CVE-2023-52615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52616" id="CVE-2023-52616" title="CVE-2023-52616" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52621" id="CVE-2023-52621" title="CVE-2023-52621" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52623" id="CVE-2023-52623" title="CVE-2023-52623" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52629" id="CVE-2023-52629" title="CVE-2023-52629" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52630" id="CVE-2023-52630" title="CVE-2023-52630" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52633" id="CVE-2023-52633" title="CVE-2023-52633" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52635" id="CVE-2023-52635" title="CVE-2023-52635" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52637" id="CVE-2023-52637" title="CVE-2023-52637" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52639" id="CVE-2023-52639" title="CVE-2023-52639" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52644" id="CVE-2023-52644" title="CVE-2023-52644" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52675" id="CVE-2023-52675" title="CVE-2023-52675" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52676" id="CVE-2023-52676" title="CVE-2023-52676" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52685" id="CVE-2023-52685" title="CVE-2023-52685" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52690" id="CVE-2023-52690" title="CVE-2023-52690" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52694" id="CVE-2023-52694" title="CVE-2023-52694" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24860" id="CVE-2024-24860" title="CVE-2024-24860" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26610" id="CVE-2024-26610" title="CVE-2024-26610" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26633" id="CVE-2024-26633" title="CVE-2024-26633" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26635" id="CVE-2024-26635" title="CVE-2024-26635" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26636" id="CVE-2024-26636" title="CVE-2024-26636" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26640" id="CVE-2024-26640" title="CVE-2024-26640" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26641" id="CVE-2024-26641" title="CVE-2024-26641" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26642" id="CVE-2024-26642" title="CVE-2024-26642" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26645" id="CVE-2024-26645" title="CVE-2024-26645" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26661" id="CVE-2024-26661" title="CVE-2024-26661" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26665" id="CVE-2024-26665" title="CVE-2024-26665" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26675" id="CVE-2024-26675" title="CVE-2024-26675" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26679" id="CVE-2024-26679" title="CVE-2024-26679" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26684" id="CVE-2024-26684" title="CVE-2024-26684" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26685" id="CVE-2024-26685" title="CVE-2024-26685" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26686" id="CVE-2024-26686" title="CVE-2024-26686" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26697" id="CVE-2024-26697" title="CVE-2024-26697" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26702" id="CVE-2024-26702" title="CVE-2024-26702" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26706" id="CVE-2024-26706" title="CVE-2024-26706" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26707" id="CVE-2024-26707" title="CVE-2024-26707" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26712" id="CVE-2024-26712" title="CVE-2024-26712" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26720" id="CVE-2024-26720" title="CVE-2024-26720" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26726" id="CVE-2024-26726" title="CVE-2024-26726" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26733" id="CVE-2024-26733" title="CVE-2024-26733" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26734" id="CVE-2024-26734" title="CVE-2024-26734" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26735" id="CVE-2024-26735" title="CVE-2024-26735" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26740" id="CVE-2024-26740" title="CVE-2024-26740" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26743" id="CVE-2024-26743" title="CVE-2024-26743" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26744" id="CVE-2024-26744" title="CVE-2024-26744" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26754" id="CVE-2024-26754" title="CVE-2024-26754" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26763" id="CVE-2024-26763" title="CVE-2024-26763" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26776" id="CVE-2024-26776" title="CVE-2024-26776" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26782" id="CVE-2024-26782" title="CVE-2024-26782" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26787" id="CVE-2024-26787" title="CVE-2024-26787" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26801" id="CVE-2024-26801" title="CVE-2024-26801" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26805" id="CVE-2024-26805" title="CVE-2024-26805" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26808" id="CVE-2024-26808" title="CVE-2024-26808" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26809" id="CVE-2024-26809" title="CVE-2024-26809" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26851" id="CVE-2024-26851" title="CVE-2024-26851" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26881" id="CVE-2024-26881" title="CVE-2024-26881" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26900" id="CVE-2024-26900" title="CVE-2024-26900" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26901" id="CVE-2024-26901" title="CVE-2024-26901" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26903" id="CVE-2024-26903" title="CVE-2024-26903" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26907" id="CVE-2024-26907" title="CVE-2024-26907" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26908" id="CVE-2024-26908" title="CVE-2024-26908" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26937" id="CVE-2024-26937" title="CVE-2024-26937" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27395" id="CVE-2024-27395" title="CVE-2024-27395" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27396" id="CVE-2024-27396" title="CVE-2024-27396" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27398" id="CVE-2024-27398" title="CVE-2024-27398" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27431" id="CVE-2024-27431" title="CVE-2024-27431" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35849" id="CVE-2024-35849" title="CVE-2024-35849" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35943" id="CVE-2024-35943" title="CVE-2024-35943" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:mm/slub: fix to return errno if kmalloc() failsIn create_unique_id(), kmalloc(, GFP_KERNEL) can fail due toout-of-memory, if it fails, return errno correctly rather thantriggering panic via BUG_ON();kernel BUG at mm/slub.c:5893!Internal error: Oops - BUG: 0 [#1] PREEMPT SMPCall 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-48659)In the Linux kernel, the following vulnerability has been resolved:gpiolib: cdev: Set lineevent_state::irq after IRQ register successfullyWhen running gpio test on nxp-ls1028 platform with below commandgpiomon --num-events=3 --rising-edge gpiochip1 25There will be a warning trace as below:Call trace:free_irq+0x204/0x360lineevent_free+0x64/0x70gpio_ioctl+0x598/0x6a0__arm64_sys_ioctl+0xb4/0x100invoke_syscall+0x5c/0x130......el0t_64_sync+0x1a0/0x1a4The reason of this issue is that calling request_threaded_irq()function failed, and then lineevent_free() is invoked to releasethe resource. Since the lineevent_state::irq was already set, sothe subsequent invocation of free_irq() would trigger the abovewarning call trace. To fix this issue, set the lineevent_state::irqafter the IRQ register successfully.(CVE-2022-48660)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 ona remote address space from Task B. For this, Task A pins the remote mmvia mmget_not_zero() first. This can race with Task B do_exit() and thefinal 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 Aas TWA_RESUME. So in theory, Task A returns to userspace and the cleanupwork gets executed. However, Task A instead sleep, waiting for a replyfrom Task B that never comes (it&#39;s dead).This means the binder_deferred_release() is blocked until an unrelatedbinder event forces Task A to go back to userspace. All the associateddeath notifications will also be delayed until then.In order to fix this use mmput_async() that will schedule the work inthe corresponding mm-&gt;async_put_work WQ instead of Task A.(CVE-2023-52609)In the Linux kernel, the following vulnerability has been resolved:hwrng: core - Fix page fault dead lock on mmap-ed hwrngThere is a dead-lock in the hwrng device read path.  This triggerswhen the user reads from /dev/hwrng into memory also mmap-ed from/dev/hwrng.  The resulting page fault triggers a recursive readwhich then dead-locks.Fix this by using a stack buffer when calling copy_to_user.(CVE-2023-52615)In the Linux kernel, the following vulnerability has been resolved:crypto: lib/mpi - Fix unexpected pointer access in mpi_ec_initWhen the mpi_ec_ctx structure is initialized, some fields are notcleared, causing a crash when referencing the field when thestructure was released. Initially, this issue was ignored becausememory for mpi_ec_ctx is allocated with the __GFP_ZERO flag.For example, this error will be triggered when calculating theZa value for SM2 separately.(CVE-2023-52616)In the Linux kernel, the following vulnerability has been resolved:bpf: Check rcu_read_lock_trace_held() before calling bpf map helpersThese three bpf_map_{lookup,update,delete}_elem() helpers are alsoavailable for sleepable bpf program, so add the corresponding lockassertion for sleepable bpf program, otherwise the following warningwill be reported when a sleepable bpf program manipulates bpf map underinterpreter 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-52621)In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix a suspicious RCU usage warningI received the following warning while running cthon against an ontapserver 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-52623)In the Linux kernel, the following vulnerability has been resolved:sh: push-switch: Reorder cleanup operations to avoid use-after-free bugThe original code puts flush_work() before timer_shutdown_sync()in switch_drv_remove(). Although we use flush_work() to stopthe 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 // useThis patch puts timer_shutdown_sync() before flush_work() tomitigate the bugs. As a result, the worker and timer will bestopped safely before the deallocate operations.(CVE-2023-52629)Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2023-52630)In the Linux kernel, the following vulnerability has been resolved:um: time-travel: fix time corruptionIn &#39;basic&#39; time-travel mode (without =inf-cpu or =ext), westill get timer interrupts. These can happen at arbitrarypoints in time, i.e. while in timer_read(), which pushestime forward just a little bit. Then, if we happen to getthe interrupt after calculating the new time to push to,but before actually finishing that, the interrupt will setthe time to a value that&#39;s incompatible with the forward,and we&#39;ll crash because time goes backwards when we do theforwarding.Fix this by reading the time_travel_time, calculating theadjustment, and doing the adjustment all with interruptsdisabled.(CVE-2023-52633)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 governordone in a loop result in timer list corruption wheretimer cancel being done from two place one fromcancel_delayed_work_sync() and followed by expire_timers()can be seen from the traces[1].while truedo        echo &#34;simple_ondemand&#34; &gt; /sys/class/devfreq/1d84000.ufshc/governor        echo &#34;performance&#34; &gt; /sys/class/devfreq/1d84000.ufshc/governordoneIt looks to be issue with devfreq driver wheredevice_monitor_[start/stop] need to synchronized so thatdelayed work should get corrupted while it is eitherbeing queued or running or being cancelled.Let&#39;s use polling flag and devfreq lock to synchronize thequeueing the timer instance twice and work data beingcorrupted.[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=0xffffff80444f0428kworker/u16:6-14217    [003]   9436.209863:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2b  now=0x10022da1c  flags=182452227vendor.xxxyyy.ha-1593    [004]   9436.209888:  timer_cancel   timer=0xffffff80444f0428vendor.xxxyyy.ha-1593    [004]   9436.216390:  timer_init   timer=0xffffff80444f0428vendor.xxxyyy.ha-1593    [004]   9436.216392:  timer_start   timer=0xffffff80444f0428  function=__typeid__ZTSFvP10timer_listE_global_addr  expires=0x10022da2c  now=0x10022da1d  flags=186646532vendor.xxxyyy.ha-1593    [005]   9436.220992:  timer_cancel   timer=0xffffff80444f0428xxxyyyTraceManag-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-52635)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-52637)In the Linux kernel, the following vulnerability has been resolved:KVM: s390: vsie: fix race during shadow creationRight now it is possible to see gmap-&gt;private being zero inkvm_s390_vsie_gmap_notifier resulting in a crash.  This is due to thefact 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-52639)In the Linux kernel, the following vulnerability has been resolved:wifi: b43: Stop/wake correct queue in DMA Tx path when QoS is disabledWhen QoS is disabled, the queue priority value will not map to the correctieee80211 queue since there is only one queue. Stop/wake queue 0 when QoSis disabled to prevent trying to stop/wake a non-existent queue and failingto 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-52644)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 memorywhich can be NULL upon failure.(CVE-2023-52675)In the Linux kernel, the following vulnerability has been resolved:bpf: Guard stack limits against 32bit overflowThis patch promotes the arithmetic around checking stack bounds to bedone in the 64-bit domain, instead of the current 32bit. The arithmeticimplies adding together a 64-bit register with a int offset. Theregister was checked to be below 1&lt;&lt;29 when it was variable, but notwhen it was fixed. The offset either comes from an instruction (in whichcase it is 16 bit), from another register (in which case the callerchecked it to be below 1&lt;&lt;29 [1]), or from the size of an argument to akfunc (in which case it can be a u32 [2]). Between the register beinginconsistently checked to be below 1&lt;&lt;29, and the offset being up to anu32, it appears that we were open to overflowing the `int`s which werecurrently 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-52676)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 return64-bit value since persistent_ram_zone::buffer_size has type size_t whichis derived from the 64-bit *unsigned long*, while the ecc_blocks variablethis value gets assigned to has (always 32-bit) *int* type.  Even if thatvalue fits into *int* type, an overflow is still possible when calculatingthe size_t typed ecc_total variable further below since there&#39;s no cast toany 64-bit type before multiplication.  Declaring the ecc_blocks variableas *size_t* should fix this mess...Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.(CVE-2023-52685)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 memorywhich can be NULL upon failure.Add a null pointer check, and release &#39;ent&#39; to avoid memory leaks.(CVE-2023-52690)In the Linux kernel, the following vulnerability has been resolved:drm/bridge: tpd12s015: Drop buggy __exit annotation for remove functionWith tpd12s015_remove() marked with __exit this function is discardedwhen the driver is compiled as a built-in. The result is that when thedriver unbinds there is no cleanup done which results in resourceleakage or worse.(CVE-2023-52694)A race condition was found in the Linux kernel&#39;s bluetooth device driver in {min,max}_key_size_set() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.(CVE-2024-24860)In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: fix a memory corruptioniwl_fw_ini_trigger_tlv::data is a pointer to a __le32, which means thatif we copy to iwl_fw_ini_trigger_tlv::data + offset while offset is inbytes, we&#39;ll write past the buffer.(CVE-2024-26610)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 bytesto skb-&gt;head. Currently we might access garbage.[1]BUG: KMSAN: uninit-value in ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0ip6_tnl_parse_tlv_enc_lim+0x94f/0xbb0ipxip6_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:4349dev_queue_xmit include/linux/netdevice.h:3134 [inline]neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592neigh_output include/net/neighbour.h:542 [inline]ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222NF_HOOK_COND include/linux/netfilter.h:303 [inline]ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243dst_output include/net/dst.h:451 [inline]ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847sock_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:2674do_syscall_x64 arch/x86/entry/common.c:52 [inline]do_syscall_64+0x44/0x110 arch/x86/entry/common.c:83entry_SYSCALL_64_after_hwframe+0x63/0x6bUninit was created at:slab_post_alloc_hook+0x129/0xa70 mm/slab.h:768slab_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:1027kmalloc_reserve+0x249/0x4a0 net/core/skbuff.c:582pskb_expand_head+0x226/0x1a00 net/core/skbuff.c:2098__pskb_pull_tail+0x13b/0x2310 net/core/skbuff.c:2655pskb_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:408ipxip6_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:4349dev_queue_xmit include/linux/netdevice.h:3134 [inline]neigh_connected_output+0x569/0x660 net/core/neighbour.c:1592neigh_output include/net/neighbour.h:542 [inline]ip6_finish_output2+0x23a9/0x2b30 net/ipv6/ip6_output.c:137ip6_finish_output+0x855/0x12b0 net/ipv6/ip6_output.c:222NF_HOOK_COND include/linux/netfilter.h:303 [inline]ip6_output+0x323/0x610 net/ipv6/ip6_output.c:243dst_output include/net/dst.h:451 [inline]ip6_local_out+0xe9/0x140 net/ipv6/output_core.c:155ip6_send_skb net/ipv6/ip6_output.c:1952 [inline]ip6_push_pending_frames+0x1f9/0x560 net/ipv6/ip6_output.c:1972rawv6_push_pending_frames+0xbe8/0xdf0 net/ipv6/raw.c:582rawv6_sendmsg+0x2b66/0x2e70 net/ipv6/raw.c:920inet_sendmsg+0x105/0x190 net/ipv4/af_inet.c:847sock_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-26633)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, &#39;)&#39;, &#34;90e5dd&#34;}}}}, 0x16)llc_conn_handler() initialises local variables {saddr,daddr}.macbased on skb in llc_pdu_decode_sa()/llc_pdu_decode_da() and passesthem to __llc_lookup().However, the initialisation is done only when skb-&gt;protocol ishtons(ETH_P_802_2), otherwise, __llc_lookup_established() and__llc_lookup_listener() will read garbage.The missing initialisation existed prior to commit 211ed865108e(&#34;net: delete all instances of special processing for token ring&#34;).It removed the part to kick out the token ring stuff but forgot toclose the door allowing ETH_P_TR_802_2 packets to sneak into llc_rcv().Let&#39;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/0x6bLocal variable daddr created at: llc_conn_handler+0x53/0x1360 net/llc/llc_conn.c:783 llc_rcv+0xfbb/0x14a0 net/llc/llc_input.c:206CPU: 1 PID: 5004 Comm: syz-executor994 Not tainted 6.6.0-syzkaller-14500-g1c41041124bd #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023(CVE-2024-26635)In the Linux kernel, the following vulnerability has been resolved:llc: make llc_ui_sendmsg() more robust against bonding changessyzbot was able to trick llc_ui_sendmsg(), allocating an skb with noheadroom, but subsequently trying to push 14 bytes of Ethernet header [1]Like some others, llc_ui_sendmsg() releases the socket lock beforecalling sock_alloc_send_skb().Then it acquires it again, but does not redo all the sanity checksthat 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 SMPModules linked in:CPU: 0 PID: 6875 Comm: syz-executor.0 Not tainted 6.7.0-rc8-syzkaller-00101-g0802e17d9aca-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023pstate: 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:203sp : ffff800096f97000x29: ffff800096f97010 x28: ffff80008cc8d668 x27: dfff800000000000x26: ffff0000cb970c90 x25: 00000000000005dc x24: ffff0000c9c36ff2x23: ffff0000c9c37000 x22: 00000000000005ea x21: 00000000000006c0x20: 000000000000000e x19: ffff800088baa334 x18: 1fffe000368261cex17: ffff80008e4ed000 x16: ffff80008a8310f8 x15: 0000000000000001x14: 1ffff00012df2d58 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000001 x10: 0000000000ff0100 x9 : e28a51f1087e8400x8 : e28a51f1087e8400 x7 : ffff80008028f8d0 x6 : 0000000000000000x5 : 0000000000000001 x4 : 0000000000000001 x3 : ffff800082b78714x2 : 0000000000000001 x1 : 0000000100000000 x0 : 0000000000000089Call 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:595Code: aa1803e6 aa1903e7 a90023f5 94792f6a (d4210000)(CVE-2024-26636)In the Linux kernel, the following vulnerability has been resolved:tcp: add sanity checks to rx zerocopyTCP rx zerocopy intent is to map pages initially allocatedfrom 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)=&#39;./file0\x00&#39;,    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)=&#39;./file0\x00&#39;,    0x181e42, 0x0)(CVE-2024-26640)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 ipv6hvariable 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/0x6bUninit 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/0x6bCPU: 0 PID: 5034 Comm: syz-executor331 Not tainted 6.7.0-syzkaller-00562-g9f8413c4a66f #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023(CVE-2024-26641)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: disallow anonymous set with timeout flagAnonymous 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-26642)In the Linux kernel, the following vulnerability has been resolved:tracing: Ensure visibility when inserting an element into tracing_mapRunning the following two commands in parallel on a multi-processorAArch64 machine can sporadically produce an unexpected warning aboutduplicate 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 thisfunction 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 &#34;memcpy(elt-&gt;key, key, map-&gt;key_size);&#34; and &#34;entry-&gt;val = elt;&#34;stores may become visible in the reversed order on another CPU. Thissecond CPU might then incorrectly determine that a new key doesn&#39;t matchan already present val-&gt;key and subse---truncated---(CVE-2024-26645)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add NULL test for &#39;timing generator&#39; in &#39;dcn21_set_pipe()&#39;In &#34;u32 otg_inst = pipe_ctx-&gt;stream_res.tg-&gt;inst;&#34;pipe_ctx-&gt;stream_res.tg could be NULL, it is relying on the caller toensure the tg is not NULL.(CVE-2024-26661)In the Linux kernel, the following vulnerability has been resolved:tunnels: fix out of bounds access when building IPv6 PMTU errorIf the ICMPv6 error is built from a non-linear skb we get the followingsplat,  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/0x6a0Use skb_checksum instead of csum_partial who cannot deal with non-linearSKBs.(CVE-2024-26665)In the Linux kernel, the following vulnerability has been resolved:ppp_async: limit MRU to 64Ksyzbot 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 (&#34;ppp: limit MRU to 64K&#34;)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:4543Modules linked in:CPU: 1 PID: 11 Comm: kworker/u4:0 Not tainted 6.8.0-rc2-syzkaller-g41bccc98fb79 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 11/17/2023Workqueue: events_unbound flush_to_ldiscpstate: 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:4537sp : ffff800093967580x29: ffff800093967660 x28: ffff8000939675a0 x27: dfff800000000000x26: ffff70001272ceb4 x25: 0000000000000000 x24: ffff8000939675c0x23: 0000000000000000 x22: 0000000000060820 x21: 1ffff0001272ceb8x20: ffff8000939675e0 x19: 0000000000000010 x18: ffff800093967120x17: ffff800083bded5c x16: ffff80008ac97500 x15: 0000000000000005x14: 1ffff0001272cebc x13: 0000000000000000 x12: 0000000000000000x11: ffff70001272cec1 x10: 1ffff0001272cec0 x9 : 0000000000000001x8 : ffff800091c91000 x7 : 0000000000000000 x6 : 000000000000003fx5 : 00000000ffffffff x4 : 0000000000000000 x3 : 0000000000000020x2 : 0000000000000008 x1 : 0000000000000000 x0 : ffff8000939675e0Call 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-26675)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_ADDRFORMsocket option and trigger a KCSAN warning.(CVE-2024-26679)In the Linux kernel, the following vulnerability has been resolved:net: stmmac: xgmac: fix handling of DPP safety error for DMA channelsCommit 56e58d6c8a56 (&#34;net: stmmac: Implement Safety Features inXGMAC core&#34;) checks and reports safety errors, but leaves theData Path Parity Errors for each channel in DMA unhandled at all, lead toa storm of interrupt.Fix it by checking and clearing the DMA_DPP_Interrupt_Status register.(CVE-2024-26684)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential bug in end_buffer_async_writeAccording to a syzbot report, end_buffer_async_write(), which handles thecompletion of block device writes, may detect abnormal condition of thebuffer async_write flag and cause a BUG_ON failure when using nilfs2.Nilfs2 itself does not use end_buffer_async_write().  But, the async_writeflag is now used as a marker by commit 7f42ec394156 (&#34;nilfs2: fix issuewith race condition of competition between segments for dirty blocks&#34;) asa means of resolving double list insertion of dirty blocks innilfs_lookup_dirty_data_buffers() and nilfs_lookup_node_buffers() and theresulting crash.This modification is safe as long as it is used for file data and b-treenode blocks where the page caches are independent.  However, it wasirrelevant and redundant to also introduce async_write for segment summaryand super root blocks that share buffers with the backing device.  Thisled to the possibility that the BUG_ON check in end_buffer_async_writewould fail as described above, if independent writebacks of the backingdevice occurred in parallel.The use of async_write for segment summary buffers has already beenremoved in a previous change.Fix this issue by removing the manipulation of the async_write flag forthe remaining super root block buffer.(CVE-2024-26685)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 statslock_task_sighand() can trigger a hard lockup.  If NR_CPUS threads calldo_task_stat() at the same time and the process has NR_THREADS, it willspin with irqs disabled O(NR_CPUS * NR_THREADS) time.Change do_task_stat() to use sig-&gt;stats_lock to gather the statisticsoutside of -&gt;siglock protected section, in the likely case this code willrun lockless.(CVE-2024-26686)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix data corruption in dsync block recovery for small block sizesThe helper function nilfs_recovery_copy_block() ofnilfs_recovery_dsync_blocks(), which recovers data from logs created bydata sync writes during a mount after an unclean shutdown, incorrectlycalculates the on-page offset when copying repair data to the file&#39;s pagecache.  In environments where the block size is smaller than the pagesize, this flaw can cause data corruption and leak uninitialized memorybytes during the recovery process.Fix these issues by correcting this byte offset calculation on the page.(CVE-2024-26697)In the Linux kernel, the following vulnerability has been resolved:iio: magnetometer: rm3100: add boundary check for the value read from RM3100_REG_TMRCRecently, we encounter kernel crash in function rm3100_common_probecaused by out of bound access of array rm3100_samp_rates (because ofunderlying hardware failures). Add boundary check to prevent out ofbound access.(CVE-2024-26702)In the Linux kernel, the following vulnerability has been resolved:parisc: Fix random data corruption from exception handlerThe current exception handler implementation, which assists when accessinguser space memory, may exhibit random data corruption if the compiler decidesto use a different register than the specified register %r29 (defined inASM_EXCEPTIONTABLE_REG) for the error code. If the compiler choose anotherregister, the fault handler will nevertheless store -EFAULT into %r29 and thustrash 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 ispossible to tell the fault handler which register is used to hold the errorcode. Using %0 or %1 in the inline assembly is not posssible as it will showup as e.g. %r29 (with the &#34;%r&#34; prefix), which the GNU assembler can notconvert 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&#34;or %r0,%r0,%reg&#34;, where %reg references the register which the compilerchoosed for the error return code.In case of an access failure, the fault handler finds the __ex_table entry andcan examine the opcode. The used register is encoded in the lowest 5 bits, andthe fault handler can then store -EFAULT into this register.Since we extend the __ex_table to 3 words we can&#39;t use the BUILDTIME_TABLE_SORTconfig option any longer.(CVE-2024-26706)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 allocateresources for skb in hsr_init_skb(). Since a WARN_ONCE() call willnot help much in this case, it might be prudent to switch tonetdev_warn_once(). At the very least it will suppress syzkallerreports such as [1].Just in case, use netdev_warn_once() in send_prp_supervision_frame()for similar reasons.[1]HSR: Could not send supervision frameWARNING: CPU: 1 PID: 85 at net/hsr/hsr_device.c:294 send_hsr_supervision_frame+0x60a/0x810 net/hsr/hsr_device.c:294RIP: 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-26707)In the Linux kernel, the following vulnerability has been resolved:powerpc/kasan: Fix addr error caused by page alignmentIn kasan_init_region, when k_start is not page aligned, at the begin offor 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 bymemblock_alloc, which will not be reserved by memblock_reserve later, itwill be used by other places.As a result, memory overwriting occurs.for example:int __init __weak kasan_init_region(void *start, size_t size){[...]&#x9;/* if say block(dcd97000) k_start(feef7400) k_end(feeff3fe) */&#x9;block = memblock_alloc(k_end - k_start, PAGE_SIZE);&#x9;[...]&#x9;for (k_cur = k_start &amp; PAGE_MASK; k_cur &lt; k_end; k_cur += PAGE_SIZE) {&#x9;&#x9;/* at the begin of for loop&#x9;&#x9; * block(dcd97000) va(dcd96c00) k_cur(feef7000) k_start(feef7400)&#x9;&#x9; * va(dcd96c00) is less than block(dcd97000), va is invalid&#x9;&#x9; */&#x9;&#x9;void *va = block + k_cur - k_start;&#x9;&#x9;[...]&#x9;}[...]}Therefore, page alignment is performed on k_start beforememblock_alloc() to ensure the validity of the VA address.(CVE-2024-26712)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 ispassed as the u32 divisor argument to div_u64().  On architectures whereunsigned long is 64 bytes, the argument will be implicitly truncated.Use div64_u64() instead of div_u64() so that the value used in the &#34;isthis a safe division&#34; check is the same as the divisor.Also, remove redundant cast of the numerator to u64, as that should happenimplicitly.This would be difficult to exploit in memcg domain, given the ratio-basedarithmetic domain_drity_limits() uses, but is much easier in globalwriteback 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-26720)In the Linux kernel, the following vulnerability has been resolved:btrfs: don&#39;t drop extent_map for free space inode on write errorWhile running the CI for an unrelated change I hit the following panicwith 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 NOPTICPU: 1 PID: 2695096 Comm: fsstress Kdump: loaded Tainted: G        W          6.8.0-rc2+ #1RIP: 0010:__extent_writepage_io.constprop.0+0x4c1/0x5c0Call 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/0x76This happens because we fail to write out the free space cache in oneinstance, come back around and attempt to write it again.  However onthe second pass through we go to call btrfs_get_extent() on the inode toget the extent mapping.  Because this is a new block group, and with thefree space inode we always search the commit root to avoid deadlockingwith the tree, we find nothing and return a EXTENT_MAP_HOLE for therequested range.This happens because the first time we try to write the space cache outwe hit an error, and on an error we drop the extent mapping.  This isnormal for normal files, but the free space cache inode is special.  Wealways expect the extent map to be correct.  Thus the second timethrough we end up with a bogus extent map.Since we&#39;re deprecating this feature, the most straightforward way tofix this is to simply skip dropping the extent map range for this failedrange.I shortened the test by using error injection to stress the area to makeit easier to reproduce.  With this patch in place we no longer panicwith my error injection test.(CVE-2024-26726)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 neighbourentry and copies neigh-&gt;ha to struct arpreq.arp_ha.sa_data.The arp_ha here is struct sockaddr, not struct sockaddr_storage, sothe 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&#39;snot 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&#39;s limit the max length of memcpy().Note that commit b5f0de6df6dc (&#34;net: dev: Convert sa_data to flexiblearray in struct sockaddr&#34;) just silenced syzkaller.[0]:memcpy: detected field-spanning write (size 16) of single field &#34;r-&gt;arp_ha.sa_data&#34; at net/ipv4/arp.c:1128 (size 14)WARNING: CPU: 0 PID: 144638 at net/ipv4/arp.c:1128 arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128Modules linked in:CPU: 0 PID: 144638 Comm: syz-executor.4 Not tainted 6.1.74 #31Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.0-debian-1.16.0-5 04/01/2014RIP: 0010:arp_req_get+0x411/0x4a0 net/ipv4/arp.c:1128Code: 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 a6RSP: 0018:ffffc900050b7998 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff88803a815000 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffffffff8641a44a RDI: 0000000000000001RBP: ffffc900050b7a98 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 203a7970636d656d R12: ffff888039c54000R13: 1ffff92000a16f37 R14: ffff88803a815084 R15: 0000000000000010FS:  00007f172bf306c0(0000) GS:ffff88805aa00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f172b3569f0 CR3: 0000000057f12005 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call 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/0xceRIP: 0033:0x7f172b262b8dCode: 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 48RSP: 002b:00007f172bf300b8 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: ffffffffffffffda RBX: 00007f172b3abf80 RCX: 00007f172b262b8dRDX: 0000000020000000 RSI: 0000000000008954 RDI: 0000000000000003RBP: 00007f172b2d3493 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 000000000000000b R14: 00007f172b3abf80 R15: 00007f172bf10000 &lt;/TASK&gt;(CVE-2024-26733)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 registeredbefore registering the generic netlink family.Make an unregister in case of unsuccessful registration.(CVE-2024-26734)In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix possible use-after-free and null-ptr-derefThe pernet operations structure for the subsystem must be registeredbefore registering the generic netlink family.(CVE-2024-26735)In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mirred: use the backlog for mirred ingressThe test Davide added in commit ca22da2fbd69 (&#34;act_mirred: use the backlogfor nested calls to mirred ingress&#34;) hangs our testing VMs every 10 or soruns, with the familiar tcp_v4_rcv -&gt; tcp_v4_rcv deadlock reported bylockdep.The problem as previously described by Davide (see Link) is thatif we reverse flow of traffic with the redirect (egress -&gt; ingress)we may reach the same socket which generated the packet. And we maystill be holding its socket lock. The common solution to such deadlocksis to put the packet in the Rx backlog, rather than run the Rx pathinline. Do that for all egress -&gt; ingress reversals, not just oncewe started to nest mirred calls.In the past there was a concern that the backlog indirection willlead to loss of error reporting / less accurate stats. But the currentworkaround does not seem to address the issue.(CVE-2024-26740)In the Linux kernel, the following vulnerability has been resolved:RDMA/qedr: Fix qedr_create_user_qp error flowAvoid the following warning by making sure to free the allocatedresources 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 tg3ghash_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 #1Hardware name: Dell Inc. PowerEdge R430/03XKDV, BIOS 2.14.0 01/25/2022RIP: 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 ffRSP: 0018:ffffb7c6cadfbc60 EFLAGS: 00010286RAX: ffff8f0889ee3f60 RBX: ffff8f088c1a5200 RCX: 00000000802a0016RDX: 00000000802a0017 RSI: 0000000000000001 RDI: ffff8f0880042600RBP: 0000000000000001 R08: 0000000000000001 R09: 0000000000000000R10: ffff8f11fffd5000 R11: 0000000000039000 R12: ffff8f0d5b36cd80R13: ffff8f088c1a5250 R14: ffff8f1206d91000 R15: 0000000000000000FS: 0000000000000000(0000) GS:ffff8f11d7c00000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000147069200e20 CR3: 00000001c7210002 CR4: 00000000001706f0Call 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/0x250task_work_run+0x5c/0x90do_exit+0x270/0x4a0do_group_exit+0x2d/0x90get_signal+0x87c/0x8c0arch_do_signal_or_restart+0x25/0x100? ib_uverbs_ioctl+0xc2/0x110 [ib_uverbs]exit_to_user_mode_loop+0x9c/0x130exit_to_user_mode_prepare+0xb6/0x100syscall_exit_to_user_mode+0x12/0x40do_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/0xa0entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x1470abe3ec6bCode: Unable to access opcode bytes at RIP 0x1470abe3ec41.RSP: 002b:00007fff13ce9108 EFLAGS: 00000246 ORIG_RAX: 0000000000000010RAX: fffffffffffffffc RBX: 00007fff13ce9218 RCX: 00001470abe3ec6bRDX: 00007fff13ce9200 RSI: 00000000c0181b01 RDI: 0000000000000004RBP: 00007fff13ce91e0 R08: 0000558d9655da10 R09: 0000558d9655dd00R10: 00007fff13ce95c0 R11: 0000000000000246 R12: 00007fff13ce9358R13: 0000000000000013 R14: 0000558d9655db50 R15: 00007fff13ce9470&lt;/TASK&gt;--[ end trace 888a9b92e04c5c97 ]--(CVE-2024-26743)In the Linux kernel, the following vulnerability has been resolved:RDMA/srpt: Support specifying the srpt_service_guid parameterMake loading ib_srpt with this parameter set work. The current behavior isthat setting that parameter while loading the ib_srpt kernel moduletriggers the following kernel crash:BUG: kernel NULL pointer dereference, address: 0000000000000000Call 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-26744)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 beregistered before registering the generic netlink family.Syzkaller hit &#39;general protection fault in gtp_genl_dump_pdp&#39; bug:general protection fault, probably for non-canonical address0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN NOPTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 PID: 5826 Comm: gtp Not tainted 6.8.0-rc3-std-def-alt1 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-alt1 04/01/2014RIP: 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 74RSP: 0018:ffff888014107220 EFLAGS: 00010202RAX: dffffc0000000000 RBX: 0000000000000000 RCX: 0000000000000000RDX: 0000000000000002 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: 0000000000000000R13: ffff88800fcda588 R14: 0000000000000001 R15: 0000000000000000FS:  00007f1be4eb05c0(0000) GS:ffff88806ce80000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1be4e766cf CR3: 000000000c33e000 CR4: 0000000000750ef0PKRU: 55555554Call 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-26754)In the Linux kernel, the following vulnerability has been resolved:dm-crypt: don&#39;t modify the data when using authenticated encryptionIt was said that authenticated encryption could produce invalid tag whenthe data that is being encrypted is modified [1]. So, fix this problem bycopying the data into the clone bio first and then encrypt them inside theclone bio.This may reduce performance, but it is needed to prevent the user fromcorrupting the device by writing data with O_DIRECT and modifying them atthe same time.[1] https://lore.kernel.org/all/20240207004723.GA35324@sol.localdomain/T/(CVE-2024-26763)In the Linux kernel, the following vulnerability has been resolved:spi: hisi-sfc-v3xx: Return IRQ_NONE if no interrupts were detectedReturn IRQ_NONE from the interrupt handler when no interrupt wasdetected. 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-26776)In the Linux kernel, the following vulnerability has been resolved:mptcp: fix double-free on socket dismantlewhen MPTCP server accepts an incoming connection, it clones its listenersocket. However, the pointer to &#39;inet_opt&#39; for the new socket has the samevalue as the original one: as a consequence, on program exit it&#39;s possibleto 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-26782)In the Linux kernel, the following vulnerability has been resolved:mmc: mmci: stm32: fix DMA API overlapping mappings warningTurning on CONFIG_DMA_API_DEBUG_SG results in the following warning:DMA-API: mmci-pl18x 48220000.mmc: cacheline tracking EEXIST,overlapping mappings aren&#39;t supportedWARNING: CPU: 1 PID: 51 at kernel/dma/debug.c:568add_dma_entry+0x234/0x2f4Modules linked in:CPU: 1 PID: 51 Comm: kworker/1:2 Not tainted 6.1.28 #1Hardware name: STMicroelectronics STM32MP257F-EV1 Evaluation Board (DT)Workqueue: events_freezable mmc_rescanCall trace:add_dma_entry+0x234/0x2f4debug_dma_map_sg+0x198/0x350__dma_map_sg_attrs+0xa0/0x110dma_map_sg_attrs+0x10/0x2csdmmc_idma_prep_data+0x80/0xc0mmci_prep_data+0x38/0x84mmci_start_data+0x108/0x2dcmmci_request+0xe4/0x190__mmc_start_request+0x68/0x140mmc_start_request+0x94/0xc0mmc_wait_for_req+0x70/0x100mmc_send_tuning+0x108/0x1acsdmmc_execute_tuning+0x14c/0x210mmc_execute_tuning+0x48/0xecmmc_sd_init_uhs_card.part.0+0x208/0x464mmc_sd_init_card+0x318/0x89cmmc_attach_sd+0xe4/0x180mmc_rescan+0x244/0x320DMA API debug brings to light leaking dma-mappings as dma_map_sg anddma_unmap_sg are not correctly balanced.If an error occurs in mmci_cmd_irq function, only mmci_dma_errorfunction is called and as this API is not managed on stm32 variant,dma_unmap_sg is never called in this error path.(CVE-2024-26787)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Avoid potential use-after-free in hci_error_resetWhile handling the HCI_EV_HARDWARE_ERROR event, if the underlyingBT controller is not responding, the GPIO reset mechanism wouldfree the hci_dev and lead to a use-after-free in hci_error_reset.Here&#39;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/0x30This patch holds the reference count on the hci_dev while processinga HCI_EV_HARDWARE_ERROR event to avoid potential crash.(CVE-2024-26801)In the Linux kernel, the following vulnerability has been resolved:netlink: Fix kernel-infoleak-after-free in __skb_datagram_itersyzbot 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 datasize 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 notinitialized when the new `skb` created, KMSAN detects uninitializedmemory 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/0x6bUninit 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/0x6bUninit 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-26805)In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_chain_filter: handle NETDEV_UNREGISTER for inet/ingress basechainRemove netdevice from inet/ingress basechain in case NETDEV_UNREGISTERevent is reported, otherwise a stale reference to netdevice remains inthe hook list.(CVE-2024-26808)In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: release elements in clone only from destroy pathClone already always provides a current view of the lookup table, use itto destroy the set, otherwise it is possible to destroy elements twice.This fix requires: 212ed75dc5fb (&#34;netfilter: nf_tables: integrate pipapo into commit protocol&#34;)which came after: 9827a0e6e23b (&#34;netfilter: nft_set_pipapo: release elements in clone from abort path&#34;).(CVE-2024-26809)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_conntrack_h323: Add protection for bmp length out of rangeUBSAN load reports an exception of BRK#5515 SHIFT_ISSUE:Bitwise shiftsthat 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 lengthexceeds 32 when decoding ras message then uses the length to makea shift operation. It will change into negative after several loop.UBSAN load could detect a negative shift as an undefined behaviourand reports exception.So we add the protection to avoid the length exceeding 32. Or elseit will return out of range error and stop decoding.(CVE-2024-26851)In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when 1588 is received on HIP08 devicesThe HIP08 devices does not register the ptp devices, so thehdev-&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, theaccess 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-26881)In the Linux kernel, the following vulnerability has been resolved:md: fix kmemleak of rdev-&gt;serialIf kobject_add() is fail in bind_rdev_to_array(), &#39;rdev-&gt;serial&#39; will bealloc not be freed, and kmemleak occurs.unreferenced object 0xffff88815a350000 (size 49152):  comm &#34;mdadm&#34;, 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-26900)In the Linux kernel, the following vulnerability has been resolved:do_sys_name_to_handle(): use kzalloc() to fix kernel-infoleaksyzbot identified a kernel information leak vulnerability indo_sys_name_to_handle() and issued the following report [1].[1]&#34;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 uninitializedMemory access of size 20 starts at ffff888128a46380Data copied to user address 0000000020000240&#34;Per Chuck Lever&#39;s suggestion, use kzalloc() instead of kmalloc() tosolve the problem.(CVE-2024-26901)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: rfcomm: Fix null-ptr-deref in rfcomm_check_securityDuring our fuzz testing of the connection and disconnection process at theRFCOMM layer, we discovered this bug. By comparing the packets from anormal connection and disconnection process with the testcase thattriggered 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 ofencryption key.After receiving this packet, the controller immediatelyreplies with a Command Completepacket (Event Code: 0x0e) to return theEncryption Key Size.2. In our fuzz test case, the timing of the controller&#39;s response to thispacket was delayed to an unexpected point: after the RFCOMM and L2CAPlayers had disconnected but before the HCI layer had disconnected.3. After receiving the Encryption Key Size Response at the time describedin 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 callingrfcomm_recv_frame in rfcomm_process_rx.(CVE-2024-26903)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 &#34;eseg-&gt;inline_hdr.start&#34; at /var/lib/dkms/mlnx-ofed-kernel/5.8/build/drivers/infiniband/hw/mlx5/wr.c:131 (size 2) 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-26907)Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-26908)In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Reset queue_priority_hint on parkingOriginally, with strict in order execution, we could complete executiononly when the queue was empty. Preempt-to-busy allows replacement of anactive request that may complete before the preemption is processed byHW. If that happens, the request is retired from the queue, but thequeue_priority_hint remains set, preventing direct submission untilafter the next CS interrupt is processed.This preempt-to-busy race can be triggered by the heartbeat, which willalso act as the power-management barrier and upon completion allow us toidle the HW. We may process the completion of the heartbeat, and beginparking the engine before the CS event that restores thequeue_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-26937)In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: Fix Use-After-Free in ovs_ct_exitSince kfree_rcu, which is called in the hlist_for_each_entry_rcu traversalof ovs_ct_limit_exit, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe key will be free.To prevent this, it should be changed to hlist_for_each_entry_safe.(CVE-2024-27395)In the Linux kernel, the following vulnerability has been resolved:net: gtp: Fix Use-After-Free in gtp_dellinkSince call_rcu, which is called in the hlist_for_each_entry_rcu traversalof gtp_dellink, is not part of the RCU read critical section, itis possible that the RCU grace period will pass during the traversal andthe 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:Bluetooth: Fix use-after-free bugs caused by sco_sock_timeoutWhen the sco connection is established and then, the sco socketis releasing, timeout_work will be scheduled to judge whetherthe sco disconnection is timeout. The sock will be deallocatedlater, but it is dereferenced again in sco_sock_timeout. As aresult, the use-after-free bugs will happen. The root cause isshown below:    Cleanup Thread               |      Worker Threadsco_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) //USEThe 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-27398)In the Linux kernel, the following vulnerability has been resolved:cpumap: Zero-initialise xdp_rxq_info struct before running XDP programWhen running an XDP program that is attached to a cpumap entry, we don&#39;tinitialise the xdp_rxq_info data structure being used in the xdp_buffthat backs the XDP program invocation. Tobias noticed that this leads torandom values being returned as the xdp_md-&gt;rx_queue_index value for XDPprograms running in a cpumap.This means we&#39;re basically returning the contents of the uninitialisedmemory, which is bad. Fix this by zero-initialising the rxq datastructure before running the XDP program.(CVE-2024-27431)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 inbtrfs_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 ffff888045a40000This happens, because we&#39;re copying a &#39;struct btrfs_data_container&#39; backto user-space. This btrfs_data_container is allocated in&#39;init_data_container()&#39; via kvmalloc(), which does not zero-fill thememory.Fix this by using kvzalloc() which zeroes out the memory on allocation.(CVE-2024-35849)In the Linux kernel, the following vulnerability has been resolved:pmdomain: ti: Add a null pointer check to the omap_prm_domain_initdevm_kasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure. Ensure the allocation was successfulby checking the pointer validity.(CVE-2024-35943)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-debugsource" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.76.0.156.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.76.0.156.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.76.0.156.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1654</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4853" id="CVE-2024-4853" title="CVE-2024-4853" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4855" id="CVE-2024-4855" title="CVE-2024-4855" type="cve"></reference>
          </references>
          <description>Memory handling issue in editcap could cause denial of service via crafted capture file(CVE-2024-4853)Use after free issue in editcap could cause denial of service via crafted capture file(CVE-2024-4855)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1662</id>
          <title>An update for git is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32002" id="CVE-2024-32002" title="CVE-2024-32002" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32004" id="CVE-2024-32004" title="CVE-2024-32004" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32020" id="CVE-2024-32020" title="CVE-2024-32020" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32021" id="CVE-2024-32021" title="CVE-2024-32021" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32465" id="CVE-2024-32465" title="CVE-2024-32465" type="cve"></reference>
          </references>
          <description>Git is a revision control system. Prior to versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4, repositories with submodules can be crafted in a way that exploits a bug in Git whereby it can be fooled into writing files not into the submodule&#39;s worktree but into a `.git/` directory. This allows writing a hook that will be executed while the clone operation is still running, giving the user no opportunity to inspect the code that is being executed. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4. If symbolic link support is disabled in Git (e.g. via `git config --global core.symlinks false`), the described attack won&#39;t work. As always, it is best to avoid cloning repositories from untrusted sources.(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, 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-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, local clones may end up hardlinking files into the target repository&#39;s object database when source and target repository reside on the same disk. If the source repository is owned by a different user, then those hardlinked files may be rewritten at any point in time by the untrusted user. Cloning local repositories will cause Git to either copy or hardlink files of the source repository into the target repository. This significantly speeds up such local clones compared to doing a &#34;proper&#34; clone and saves both disk space and compute time. When cloning a repository located on the same disk that is owned by a different user than the current user we also end up creating such hardlinks. These files will continue to be owned and controlled by the potentially-untrusted user and can be rewritten by them at will in the future. The problem has been patched in versions 2.45.1, 2.44.1, 2.43.4, 2.42.2, 2.41.1, 2.40.2, and 2.39.4.(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, when cloning a local source repository that contains symlinks via the filesystem, Git may create hardlinks to arbitrary user-readable files on the same filesystem as the target repository in the `objects/` directory. Cloning a local repository over the filesystem may creating hardlinks to arbitrary user-owned files on the same filesystem in the target Git repository&#39;s `objects/` directory. When cloning a repository over the filesystem (without explicitly specifying the `file://` protocol or `--no-local`), the optimizations for local cloningwill 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-32021)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-32465)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="git-daemon" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-core" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debuginfo" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="git-debugsource" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-web" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-web-2.33.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-gui" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-gui-2.33.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-svn" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-svn-2.33.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git-SVN" release="15.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-SVN-2.33.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="perl-Git" release="15.oe2203sp1" version="2.33.0">
                         <filename>perl-Git-2.33.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="gitk" release="15.oe2203sp1" version="2.33.0">
                         <filename>gitk-2.33.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-email" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-email-2.33.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="git-help" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-help-2.33.0-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-daemon" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-daemon-2.33.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-2.33.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debuginfo" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-debuginfo-2.33.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-core" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-core-2.33.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="git-debugsource" release="15.oe2203sp1" version="2.33.0">
                         <filename>git-debugsource-2.33.0-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1663</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-1916" id="CVE-2023-1916" title="CVE-2023-1916" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-3164" id="CVE-2023-3164" title="CVE-2023-3164" type="cve"></reference>
          </references>
          <description>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-1916)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.(CVE-2023-3164)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff-static" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-tools" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-37.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="37.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1666</id>
          <title>An update for giflib is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-24"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-40633" id="CVE-2021-40633" title="CVE-2021-40633" type="cve"></reference>
          </references>
          <description>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.(CVE-2021-40633)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="giflib-devel" release="8.oe2203sp1" version="5.2.1">
                         <filename>giflib-devel-5.2.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="giflib" release="8.oe2203sp1" version="5.2.1">
                         <filename>giflib-5.2.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="giflib-utils" release="8.oe2203sp1" version="5.2.1">
                         <filename>giflib-utils-5.2.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="giflib-help" release="8.oe2203sp1" version="5.2.1">
                         <filename>giflib-help-5.2.1-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib-devel" release="8.oe2203sp1" version="5.2.1">
                         <filename>giflib-devel-5.2.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib" release="8.oe2203sp1" version="5.2.1">
                         <filename>giflib-5.2.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib-utils" release="8.oe2203sp1" version="5.2.1">
                         <filename>giflib-utils-5.2.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1667</id>
          <title>An update for infinispan is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-10174" id="CVE-2019-10174" title="CVE-2019-10174" type="cve"></reference>
          </references>
          <description>A vulnerability was found in Infinispan such that the invokeAccessibly method from the public class ReflectionUtil allows any application class to invoke private methods in any class with Infinispan&#39;s privileges. The attacker can use reflection to introduce new, malicious behavior into the application.(CVE-2019-10174)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="infinispan" release="13.oe2203sp1" version="8.2.4">
                         <filename>infinispan-8.2.4-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="infinispan-help" release="13.oe2203sp1" version="8.2.4">
                         <filename>infinispan-help-8.2.4-13.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1672</id>
          <title>An update for containers-common is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1962" id="CVE-2022-1962" title="CVE-2022-1962" type="cve"></reference>
          </references>
          <description>Uncontrolled recursion in the Parse functions in go/parser before Go 1.17.12 and Go 1.18.4 allow an attacker to cause a panic due to stack exhaustion via deeply nested types or declarations.(CVE-2022-1962)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="containers-common" release="3.oe2203sp1" version="1">
                         <filename>containers-common-1-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1674</id>
          <title>An update for openjdk-1.8.0 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-05-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21085" id="CVE-2024-21085" title="CVE-2024-21085" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"></reference>
          </references>
          <description>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-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-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-21068)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).(CVE-2024-21085)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-21094)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debuginfo" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-headless-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-debugsource" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-devel-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-demo-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-openjfx" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-1.8.0-openjdk-src" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-src-1.8.0.412.b08-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc-zip" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.412.b08-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="java-1.8.0-openjdk-javadoc" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-javadoc-1.8.0.412.b08-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-src" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-src-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debuginfo" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-debugsource" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-devel" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-demo" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-1.8.0-openjdk-headless-slowdebug" release="5.oe2203sp1" version="1.8.0.412.b08">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.412.b08-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1680</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47421" id="CVE-2021-47421" title="CVE-2021-47421" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47455" id="CVE-2021-47455" title="CVE-2021-47455" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48641" id="CVE-2022-48641" title="CVE-2022-48641" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48708" id="CVE-2022-48708" title="CVE-2022-48708" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52650" id="CVE-2023-52650" title="CVE-2023-52650" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52656" id="CVE-2023-52656" title="CVE-2023-52656" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52664" id="CVE-2023-52664" title="CVE-2023-52664" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52683" id="CVE-2023-52683" title="CVE-2023-52683" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52698" id="CVE-2023-52698" title="CVE-2023-52698" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52809" id="CVE-2023-52809" title="CVE-2023-52809" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52813" id="CVE-2023-52813" title="CVE-2023-52813" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52817" id="CVE-2023-52817" title="CVE-2023-52817" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52835" id="CVE-2023-52835" title="CVE-2023-52835" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52837" id="CVE-2023-52837" title="CVE-2023-52837" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52840" id="CVE-2023-52840" title="CVE-2023-52840" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52844" id="CVE-2023-52844" title="CVE-2023-52844" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52847" id="CVE-2023-52847" title="CVE-2023-52847" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52854" id="CVE-2023-52854" title="CVE-2023-52854" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52860" id="CVE-2023-52860" title="CVE-2023-52860" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52863" id="CVE-2023-52863" title="CVE-2023-52863" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52867" id="CVE-2023-52867" title="CVE-2023-52867" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52869" id="CVE-2023-52869" title="CVE-2023-52869" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52876" id="CVE-2023-52876" title="CVE-2023-52876" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52879" id="CVE-2023-52879" title="CVE-2023-52879" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26814" id="CVE-2024-26814" title="CVE-2024-26814" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26923" id="CVE-2024-26923" title="CVE-2024-26923" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26950" id="CVE-2024-26950" title="CVE-2024-26950" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26958" id="CVE-2024-26958" title="CVE-2024-26958" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26961" id="CVE-2024-26961" title="CVE-2024-26961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26965" id="CVE-2024-26965" title="CVE-2024-26965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26972" id="CVE-2024-26972" title="CVE-2024-26972" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26976" id="CVE-2024-26976" title="CVE-2024-26976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26982" id="CVE-2024-26982" title="CVE-2024-26982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26993" id="CVE-2024-26993" title="CVE-2024-26993" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27000" id="CVE-2024-27000" title="CVE-2024-27000" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27008" id="CVE-2024-27008" title="CVE-2024-27008" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27045" id="CVE-2024-27045" title="CVE-2024-27045" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27059" id="CVE-2024-27059" title="CVE-2024-27059" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27072" id="CVE-2024-27072" title="CVE-2024-27072" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27073" id="CVE-2024-27073" title="CVE-2024-27073" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27075" id="CVE-2024-27075" title="CVE-2024-27075" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27389" id="CVE-2024-27389" title="CVE-2024-27389" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27407" id="CVE-2024-27407" title="CVE-2024-27407" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27419" id="CVE-2024-27419" title="CVE-2024-27419" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27426" id="CVE-2024-27426" title="CVE-2024-27426" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27427" id="CVE-2024-27427" title="CVE-2024-27427" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35791" id="CVE-2024-35791" title="CVE-2024-35791" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35801" id="CVE-2024-35801" title="CVE-2024-35801" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35805" id="CVE-2024-35805" title="CVE-2024-35805" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35806" id="CVE-2024-35806" title="CVE-2024-35806" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35818" id="CVE-2024-35818" title="CVE-2024-35818" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35835" id="CVE-2024-35835" title="CVE-2024-35835" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35844" id="CVE-2024-35844" title="CVE-2024-35844" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35845" id="CVE-2024-35845" title="CVE-2024-35845" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35848" id="CVE-2024-35848" title="CVE-2024-35848" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35898" id="CVE-2024-35898" title="CVE-2024-35898" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35922" id="CVE-2024-35922" title="CVE-2024-35922" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35930" id="CVE-2024-35930" title="CVE-2024-35930" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35936" id="CVE-2024-35936" title="CVE-2024-35936" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35940" id="CVE-2024-35940" title="CVE-2024-35940" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35976" id="CVE-2024-35976" title="CVE-2024-35976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35997" id="CVE-2024-35997" title="CVE-2024-35997" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36006" id="CVE-2024-36006" title="CVE-2024-36006" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: handle the case of pci_channel_io_frozen only in amdgpu_pci_resumeIn 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 PCIdriver will continue the execution of PCI resume callback report_resume bypci_walk_bridge, and the callback will go into amdgpu_pci_resumefinally, where write lock is releasd unconditionally without acquiringsuch lock first. In this case, a deadlock will happen when other threadsstart to acquire the read lock.To fix this, add a member in amdgpu_device strucutre to cachepci_channel_state, and only continue the execution in amdgpu_pci_resumewhen it&#39;s pci_channel_io_frozen.(CVE-2021-47421)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 &#34;i2c-idt82p33931&#34;, 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 allocatedin dev_set_name() will be leaked, the put_device() should be usedto give up the device reference, then the name will be freed inkobject_cleanup() and other memory will be freed in ptp_clock_release().(CVE-2021-47455)In the Linux kernel, the following vulnerability has been resolved:netfilter: ebtables: fix memory leak when blob is malformedThe bug fix was incomplete, it &#34;replaced&#34; crash with a memory leak.The old code had an assignment to &#34;ret&#34; embedded into the conditional,restore this.(CVE-2022-48641)In the Linux kernel, the following vulnerability has been resolved:pinctrl: single: fix potential NULL dereferenceAdded checking of pointer &#34;function&#34; in pcs_set_mux().pinmux_generic_get_function() can return NULL and the pointer&#34;function&#34; was dereferenced without checking against NULL.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2022-48708)In the Linux kernel, the following vulnerability has been resolved:drm/tegra: dsi: Add missing check for of_find_device_by_nodeAdd check for the return value of of_find_device_by_node() and returnthe error if it fails in order to avoid NULL pointer dereference.(CVE-2023-52650)In the Linux kernel, the following vulnerability has been resolved:io_uring: drop any code related to SCM_RIGHTSThis is dead code after we dropped support for passing io_uring fdsover SCM_RIGHTS, get rid of it.(CVE-2023-52656)In the Linux kernel, the following vulnerability has been resolved:net: atlantic: eliminate double free in error handling logicDriver 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 isnot 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_freeon higher layer.(CVE-2023-52664)In the Linux kernel, the following vulnerability has been resolved:ACPI: LPIT: Avoid u32 multiplication overflowIn lpit_update_residency() there is a possibility of overflowin 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-52683)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&#39;t called,and the netlbl_calipso_ops_get() function always returns NULL.In this case, the netlbl_calipso_add_pass() function allocates memoryfor the doi_def variable but doesn&#39;t free it with the calipso_doi_free().BUG: memory leakunreferenced object 0xffff888011d68180 (size 64):  comm &#34;syz-executor.1&#34;, 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/0xc6Found by InfoTeCS on behalf of Linux Verification Center(linuxtesting.org) with Syzkaller[PM: merged via the LSM tree at Jakub Kicinski request](CVE-2023-52698)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. Addressthis issue by checking return value of fc_rport_create() and log errormessage on fc_rport_create() failed.(CVE-2023-52809)In the Linux kernel, the following vulnerability has been resolved:crypto: pcrypt - Fix hungtask for PADATA_RESETWe found a hungtask bug in test_aead_vec_cfg as follows:INFO: task cryptomgr_test:391009 blocked for more than 120 seconds.&#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.Call trace: __switch_to+0x98/0xe0 __schedule+0x6c4/0xf40 schedule+0xd8/0x1b4 schedule_timeout+0x474/0x560 wait_for_common+0x368/0x4e0 wait_for_completion+0x20/0x30 wait_for_completion+0x20/0x30 test_aead_vec_cfg+0xab4/0xd50 test_aead+0x144/0x1f0 alg_test_aead+0xd8/0x1e0 alg_test+0x634/0x890 cryptomgr_test+0x40/0x70 kthread+0x1e0/0x220 ret_from_fork+0x10/0x18 Kernel panic - not syncing: hung_task: blocked tasksFor padata_do_parallel, when the return err is 0 or -EBUSY, it will callwait_for_completion(&amp;wait-&gt;completion) in test_aead_vec_cfg. In normalcase, aead_request_complete() will be called in pcrypt_aead_serial and thereturn err is 0 for padata_do_parallel. But, when pinst-&gt;flags isPADATA_RESET, the return err is -EBUSY for padata_do_parallel, and itwon&#39;t call aead_request_complete(). Therefore, test_aead_vec_cfg willhung at wait_for_completion(&amp;wait-&gt;completion), which will causehungtask.The problem comes as following:(padata_do_parallel)                 |    rcu_read_lock_bh();              |    err = -EINVAL;                   |   (padata_replace)                                     |     pinst-&gt;flags |= PADATA_RESET;    err = -EBUSY                     |    if (pinst-&gt;flags &amp; PADATA_RESET) |        rcu_read_unlock_bh()         |        return errIn order to resolve the problem, we replace the return err -EBUSY with-EAGAIN, which means parallel_data is changing, and the caller should callit again.v3:remove retry and just change the return err.v2:introduce padata_try_do_parallel() in pcrypt_aead_encrypt andpcrypt_aead_decrypt to solve the hungtask.(CVE-2023-52813)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix a null pointer access when the smc_rreg pointer is NULLIn 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/02. Execute command: cat amdgpu_regs_smc3. 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-52817)In the Linux kernel, the following vulnerability has been resolved:perf/core: Bail out early if the request AUX area is out of boundWhen 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():&#x9;------------[ cut here ]------------&#x9;WARNING: CPU: 44 PID: 17573 at mm/page_alloc.c:5568 __alloc_pages+0x1ec/0x248&#x9;Call trace:&#x9; __alloc_pages+0x1ec/0x248&#x9; __kmalloc_large_node+0xc0/0x1f8&#x9; __kmalloc_node+0x134/0x1e8&#x9; rb_alloc_aux+0xe0/0x298&#x9; perf_mmap+0x440/0x660&#x9; mmap_region+0x308/0x8a8&#x9; do_mmap+0x3c0/0x528&#x9; vm_mmap_pgoff+0xf4/0x1b8&#x9; ksys_mmap_pgoff+0x18c/0x218&#x9; __arm64_sys_mmap+0x38/0x58&#x9; invoke_syscall+0x50/0x128&#x9; el0_svc_common.constprop.0+0x58/0x188&#x9; do_el0_svc+0x34/0x50&#x9; el0_svc+0x34/0x108&#x9; el0t_64_sync_handler+0xb8/0xc0&#x9; el0t_64_sync+0x1a4/0x1a8&#39;rb-&gt;aux_pages&#39; allocated by kcalloc() is a pointer array which is used tomaintains AUX trace pages. The allocated page for this array is physicallycontiguous (and virtually contiguous) with an order of 0..MAX_ORDER. If thesize of pointer array crosses the limitation set by MAX_ORDER, it reveals aWARNING.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-52835)In the Linux kernel, the following vulnerability has been resolved:nbd: fix uaf in nbd_openCommit 4af5f2e03013 (&#34;nbd: use blk_mq_alloc_disk andblk_cleanup_disk&#34;) cleans up disk by blk_cleanup_disk() and it won&#39;t setdisk-&gt;private_data as NULL as before. UAF may be triggered in nbd_open()if someone tries to open nbd device right after nbd_put() since nbd hasbeen free in nbd_dev_remove().Fix this by implementing -&gt;free_disk and free private data in it.(CVE-2023-52837)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 &#34;fn&#34; so thedereference on the next line &#34;fn-&gt;num_of_irqs&#34; is a use after free.Move the put_device() to the end to fix this.(CVE-2023-52840)In the Linux kernel, the following vulnerability has been resolved:media: vidtv: psi: Add check for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.(CVE-2023-52844)In the Linux kernel, the following vulnerability has been resolved:media: bttv: fix use after free error due to btv-&gt;timeout timerThere may be some a race condition between timer functionbttv_irq_timeout and bttv_remove. The timer is setup inprobe and there is no timer_delete operation in removefunction. When it hit kfree btv, the function might still beinvoked, 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-52847)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 leadto system UAF (Use-After-Free) issues. Due to the lengthy analysis ofthe pcrypt_aead01 function call, I&#39;ll describe the problem scenariousing a simplified model:Suppose there&#39;s a user of padata named `user_function` that adheres tothe padata requirement of calling `padata_free_shell` after `serial()`has been invoked, as demonstrated in the following code:```cstruct 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,    &#x9;&#x9;&#x9;&#x9;struct request,&#x9;&#x9;&#x9;&#x9;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&#39;s the following code:```cstatic 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 unexecutedsoftirq at this moment, `local_bh_enable()` in padata takes longerto execute than usual. Subsequently, when accessing `pd-&gt;refcnt`,`pd` has already been released by `padata_free_shell()`, resultingin 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-52854)In the Linux kernel, the following vulnerability has been resolved:drivers/perf: hisi: use cpuhp_state_remove_instance_nocalls() for hisi_hns3_pmu uninit processWhen tearing down a &#39;hisi_hns3&#39; PMU, we mistakenly run the CPU hotplugcallbacks after the device has been unregistered, leading to fireworkswhen 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 ofcpuhp_state_remove_instance() so that the notifiers don&#39;t execute afterthe PMU device has been unregistered.[will: Rewrote commit message](CVE-2023-52860)In the Linux kernel, the following vulnerability has been resolved:hwmon: (axi-fan-control) Fix possible NULL pointer dereferenceaxi_fan_control_irq_handler(), dependent on the privateaxi_fan_control_data structure, might be called before the hwmondevice is registered. That will cause an &#34;Unable to handle kernelNULL pointer dereference&#34; error.(CVE-2023-52863)In the Linux kernel, the following vulnerability has been resolved:drm/radeon: possible buffer overflowBuffer &#39;afmt_status&#39; of size 6 could overflow, since index &#39;afmt_idx&#39; ischecked after access.(CVE-2023-52867)In the Linux kernel, the following vulnerability has been resolved:pstore/platform: Add check for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.(CVE-2023-52869)In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: clk-mt7629-eth: Add check for mtk_alloc_clk_dataAdd the check for the return value of mtk_alloc_clk_data() in order toavoid NULL pointer dereference.(CVE-2023-52876)In the Linux kernel, the following vulnerability has been resolved:tracing: Have trace_event_file have ref countersThe following can crash the kernel: # cd /sys/kernel/tracing # echo &#39;p:sched schedule&#39; &gt; kprobe_events # exec 5&gt;&gt;events/kprobes/sched/enable # &gt; kprobe_events # exec 5&gt;&amp;-The above commands: 1. Change directory to the tracefs directory 2. Create a kprobe event (doesn&#39;t matter what one) 3. Open bash file descriptor 5 on the enable file of the kprobe event 4. Delete the kprobe event (removes the files too) 5. Close the bash file descriptor 5The above causes a crash! BUG: kernel NULL pointer dereference, address: 0000000000000028 #PF: supervisor read access in kernel mode #PF: error_code(0x0000) - not-present page PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP PTI CPU: 6 PID: 877 Comm: bash Not tainted 6.5.0-rc4-test-00008-g2c6b6b1029d4-dirty #186 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.2-debian-1.16.2-1 04/01/2014 RIP: 0010:tracing_release_file_tr+0xc/0x50What happens here is that the kprobe event creates a trace_event_file&#34;file&#34; descriptor that represents the file in tracefs to the event. Itmaintains state of the event (is it enabled for the given instance?).Opening the &#34;enable&#34; file gets a reference to the event &#34;file&#34; descriptorvia the open file descriptor. When the kprobe event is deleted, the file isalso deleted from the tracefs system which also frees the event &#34;file&#34;descriptor.But as the tracefs file is still opened by user space, it will not betotally removed until the final dput() is called on it. But this is nottrue with the event &#34;file&#34; descriptor that is already freed. If the userdoes a write to or simply closes the file descriptor it will reference theevent &#34;file&#34; descriptor that was just freed, causing a use-after-free bug.To solve this, add a ref count to the event &#34;file&#34; descriptor as well as anew flag called &#34;FREED&#34;. The &#34;file&#34; will not be freed until the lastreference is released. But the FREE flag will be set when the event isremoved to prevent any more modifications to that event from happening,even if there&#39;s still a reference to the event &#34;file&#34; descriptor.(CVE-2023-52879)In the Linux kernel, the following vulnerability has been resolved:vfio/fsl-mc: Block calling interrupt handler without triggerThe eventfd_ctx trigger pointer of the vfio_fsl_mc_irq object isinitially NULL and may become NULL if the user sets the triggereventfd to -1.  The interrupt handler itself is guaranteed thattrigger is always valid between request_irq() and free_irq(), butthe loopback testing mechanisms to invoke the handler functionneed to test the trigger.  The triggering and setting ioctl pathsboth make use of igate and are therefore mutually exclusive.The vfio-fsl-mc driver does not make use of irqfds, nor does itsupport any sort of masking operations, therefore unlike vfio-pciand vfio-platform, the flow can remain essentially unchanged.(CVE-2024-26814)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 gettingenqueued during the garbage collection. If such embryo has a peer thatcarries SCM_RIGHTS, two consecutive passes of scan_children() may see adifferent set of children. Leading to an incorrectly elevated inflightcount, and then a dangling pointer within the gc_inflight_list.sockets are AF_UNIX/SOCK_STREAMS is an unconnected socketL is a listening in-flight socket bound to addr, not in fdtableV&#39;s fd will be passed via sendmsg(), gets inflight count bumpedconnect(S, addr)&#x9;sendmsg(S, [V]); close(V)&#x9;__unix_gc()----------------&#x9;-------------------------&#x9;-----------NS = unix_create1()skb1 = sock_wmalloc(NS)L = unix_find_other(addr)unix_state_lock(L)unix_peer(S) = NS&#x9;&#x9;&#x9;// V count=1 inflight=0 &#x9;&#x9;&#x9;NS = unix_peer(S) &#x9;&#x9;&#x9;skb2 = sock_alloc()&#x9;&#x9;&#x9;skb_queue_tail(NS, skb2[V])&#x9;&#x9;&#x9;// V became in-flight&#x9;&#x9;&#x9;// V count=2 inflight=1&#x9;&#x9;&#x9;close(V)&#x9;&#x9;&#x9;// V count=1 inflight=1&#x9;&#x9;&#x9;// GC candidate condition met&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;for u in gc_inflight_list:&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;  if (total_refs == inflight_refs)&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;    add u to gc_candidates&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// gc_candidates={L, V}&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;for u in gc_candidates:&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;  scan_children(u, dec_inflight)&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// embryo (skb1) was not&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// reachable from L yet, so V&#39;s&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// inflight remains unchanged__skb_queue_tail(L, skb1)unix_state_unlock(L)&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;for u in gc_candidates:&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;  if (u.inflight)&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;    scan_children(u, inc_inflight_move_tail)&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;// V count=1 inflight=2 (!)If there is a GC-candidate listening socket, lock/unlock its state. Thismakes GC wait until the end of any ongoing connect() to that socket. Afterflipping the lock, a possibly SCM-laden embryo is already enqueued. And ifthere is another embryo coming, it can not possibly carry SCM_RIGHTS. Atthis point, unix_inflight() can not happen because unix_gc_lock is alreadytaken. Inflight graph remains unaffected.(CVE-2024-26923)In the Linux kernel, the following vulnerability has been resolved:wireguard: netlink: access device through ctx instead of peerThe previous commit fixed a bug that led to a NULL peer-&gt;device beingdereferenced. It&#39;s actually easier and faster performance-wise toinstead get the device from ctx-&gt;wg. This semantically makes more sensetoo, since ctx-&gt;wg-&gt;peer_allowedips.seq is compared withctx-&gt;allowedips_seq, basing them both in ctx. This also acts as adefence in depth provision against freed peers.(CVE-2024-26950)In the Linux kernel, the following vulnerability has been resolved:nfs: fix UAF in direct writesIn 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/0xe0Workqueue: nfsiod nfs_direct_write_schedule_work [nfs]RIP: 0010:refcount_warn_saturate+0x9c/0xe0PKRU: 55555554Call 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/0x30This is because we&#39;re completing the nfs_direct_request twice in a row.The source of this is when we have our commit requests to submit, weprocess them and send them off, and then in the completion path for thecommit requests we haveif (nfs_commit_end(cinfo.mds))&#x9;nfs_direct_write_complete(dreq);However since we&#39;re submitting asynchronous requests we sometimes haveone that completes before we submit the next one, so we end up callingcomplete 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 anfs_commit_begin();nfs_commit_end();Which is a common pattern for this style of completion handling, onethat 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 popevery 10ish minutes.  With my patch the stress test has been running forseveral hours without popping.(CVE-2024-26958)In the Linux kernel, the following vulnerability has been resolved:mac802154: fix llsec key resources release in mac802154_llsec_key_delmac802154_llsec_key_del() can free resources of a key directly withoutfollowing the RCU rules for waiting before the end of a grace period. Thismay lead to use-after-free in case llsec_lookup_key() is traversing thelist 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/0x2a0Modules linked in:CPU: 4 PID: 16000 Comm: wpan-ping Not tainted 6.7.0 #19Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.2-debian-1.16.2-1 04/01/2014RIP: 0010:refcount_warn_saturate+0x162/0x2a0Call 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/0x76Also, ieee802154_llsec_key_entry structures are not freed bymac802154_llsec_key_del():unreferenced object 0xffff8880613b6980 (size 64):  comm &#34;iwpan&#34;, 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.......&#34;.......    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/0x76Handle the proper resource release in the RCU callback functionmac802154_llsec_key_del_rcu().Note that if llsec_lookup_key() finds a key, it gets a refcount viallsec_key_get() and locally copies key id from key_entry (which is alist element). So it&#39;s safe to call llsec_key_put() and free the listentry after the RCU grace period elapses.Found by Linux Verification Center (linuxtesting.org).(CVE-2024-26961)In the Linux kernel, the following vulnerability has been resolved:clk: qcom: mmcc-msm8974: fix terminating of frequency table arraysThe frequency table arrays are supposed to be terminated with anempty element. Add such entry to the end of the arrays where itis missing in order to avoid possible out-of-bound access whenthe table is traversed by functions like qcom_find_freq() orqcom_find_freq_floor().Only compile tested.(CVE-2024-26965)In the Linux kernel, the following vulnerability has been resolved:ubifs: ubifs_symlink: Fix memleak of inode-&gt;i_link in error pathFor error handling path in ubifs_symlink(), inode will be marked asbad first, then iput() is invoked. If inode-&gt;i_link is initialized byfscrypt_encrypt_symlink() in encryption scenario, inode-&gt;i_link won&#39;tbe freed by callchain ubifs_free_inode -&gt; fscrypt_free_inode in errorhandling path, because make_bad_inode() has changed &#39;inode-&gt;i_mode&#39; as&#39;S_IFREG&#39;.Following kmemleak is easy to be reproduced by injecting error inubifs_jnl_update() when doing symlink in encryption scenario: unreferenced object 0xffff888103da3d98 (size 8):  comm &#34;ln&#34;, 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/0xe0There 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-26972)In the Linux kernel, the following vulnerability has been resolved:KVM: Always flush async #PF workqueue when vCPU is being destroyedAlways flush the per-vCPU async #PF workqueue when a vCPU is clearing itscompletion 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 thelast reference to the KVM _module_ is put.  Gifting a reference to theassociated VM prevents the workqueue callback from dereferencing freedvCPU/VM memory, but does not prevent the KVM module from being unloadedbefore the callback completes.Drop the misguided VM refcount gifting, as calling kvm_put_kvm() fromasync_pf_execute() if kvm_put_kvm() flushes the async #PF workqueue willresult in deadlock.  async_pf_execute() can&#39;t return until kvm_put_kvm()finishes, and kvm_put_kvm() can&#39;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 &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; 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&#39;s no need to gift async_pf_execute() a reference because allinvocations of async_pf_execute() will be forced to complete before thevCPU and its VM are destroyed/freed.  And that in turn fixes the moduleunloading bug as __fput() won&#39;t do module_put() on the last vCPU referenceuntil the vCPU has been freed, e.g. if closing the vCPU file also puts thelast reference to the KVM module.Note that kvm_check_async_pf_completion() may also take the work item offthe completion queue and so also needs to flush the work queue, as thework will not be seen by kvm_clear_async_pf_completion_queue().  Waitingon the workqueue could theoretically delay a vCPU due to waiting for thework to complete, but that&#39;s a very, very small chance, and likely a verysmall delay.  kvm_arch_async_page_present_queued() unconditionally makes anew request, i.e. will effectively delay entering the guest, so theremaining work is really just:        trace_kvm_async_pf_completed(addr, cr2_or_gpa);        __kvm_vcpu_wake_up(vcpu);        mmput(mm);and mmput() can&#39;t drop the last reference to the page tables if the vCPU isstill alive, i.e. the vCPU won&#39;t get stuck tearing down page tables.Add a helper to do the flushing, specifically to deal with &#34;wakeup all&#34;work items, as they aren&#39;t actually work items, i.e. are never placed in aworkqueue.  Trying to flush a bogus workqueue entry rightly makes__flush_work() complain (kudos to whoever added that sanity check).Note, commit 5f6de5cbebee (&#34;KVM: Prevent module exit until al---truncated---(CVE-2024-26976)In the Linux kernel, the following vulnerability has been resolved:Squashfs: check the inode number is not the invalid value of zeroSyskiller has produced an out of bounds access in fill_meta_index().That out of bounds access is ultimately caused because the inodehas 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 followingsequence 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&#39;t been, an out of bounds access is performed.This patch adds a sanity check which checks that the inode numberis 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-26982)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 referenceleak in its error path.  If the call to kernfs_find_and_get() fails thenkn will be NULL, so the companion sysfs_unbreak_active_protection()routine won&#39;t get called (and would only cause an access violation bytrying to dereference kn-&gt;parent if it was called).  As a result, thereference to kobj acquired at the start of the function will never bereleased.Fix the leak by adding an explicit kobject_put() call when kn is NULL.(CVE-2024-26993)In the Linux kernel, the following vulnerability has been resolved:serial: mxs-auart: add spinlock around changing cts stateThe uart_handle_cts_change() function in serial_core expects the callerto 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-27000)In the Linux kernel, the following vulnerability has been resolved:drm: nv04: Fix out of bounds accessWhen Output Resource (dcb-&gt;or) value is assigned infabricate_dcb_output(), there may be out of bounds access todac_users array in case dcb-&gt;or is zero because ffs(dcb-&gt;or) isused as index there.The &#39;or&#39; argument of fabricate_dcb_output() must be interpreted as anumber of bit to set, not value.Utilize macros from &#39;enum nouveau_or&#39; in calls instead of hardcoding.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-27008)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix a potential buffer overflow in &#39;dp_dsc_clock_en_read()&#39;Tell snprintf() to store at most 10 bytes in the output bufferinstead of 30.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/amdgpu_dm/amdgpu_dm_debugfs.c:1508 dp_dsc_clock_en_read() error: snprintf() is printing too much 30 vs 10(CVE-2024-27045)In the Linux kernel, the following vulnerability has been resolved:USB: usb-storage: Prevent divide-by-0 error in isd200_ata_commandThe isd200 sub-driver in usb-storage uses the HEADS and SECTORS valuesin the ATA ID information to calculate cylinder and head values whencreating a CDB for READ or WRITE commands.  The calculation involvesdivision and modulus operations, which will cause a crash if either ofthese values is 0.  While this never happens with a genuine device, itcould happen with a flawed or subversive emulation, as reported by thesyzbot fuzzer.Protect against this possibility by refusing to bind to the device ifeither the ATA_ID_HEADS or ATA_ID_SECTORS value in the device&#39;s IDinformation is 0.  This requires isd200_Initialization() to return anegative error code when initialization fails; currently it alwaysreturns 0 (even when there is an error).(CVE-2024-27059)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() becauseare useless and may led to a deadlock as reported here:https://syzkaller.appspot.com/x/bisect.txt?x=166dc872180000Also remove usbtv_stop() call since it will be called whenunregistering the device.Before &#39;c838530d230b&#39; this issue would only be noticed if youdisconnect while streaming and now it is noticeable even whendisconnecting while not streaming.[hverkuil: fix minor spelling mistake in log message](CVE-2024-27072)In the Linux kernel, the following vulnerability has been resolved:media: ttpci: fix two memleaks in budget_av_attachWhen saa7146_register_device and saa7146_vv_init fails, budget_av_attachshould free the resources it allocates, like the error-handling ofttpci_budget_init does. Besides, there are two fixme comment refers tosuch deallocations.(CVE-2024-27073)In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: avoid stack overflow warnings with clangA previous patch worked around a KASAN issue in stv0367, now a similarproblem showed up with clang:drivers/media/dvb-frontends/stv0367.c:1222:12: error: stack frame size (3624) exceeds limit (2048) in &#39;stv0367ter_set_frontend&#39; [-Werror,-Wframe-larger-than] 1214 | static int stv0367ter_set_frontend(struct dvb_frontend *fe)Rework the stv0367_writereg() function to be simpler and mark bothregister access functions as noinline_for_stack so the temporaryi2c_msg structures do not get duplicated on the stack when KASAN_STACKis enabled.(CVE-2024-27075)In the Linux kernel, the following vulnerability has been resolved:pstore: inode: Only d_invalidate() is neededUnloading a modular pstore backend with records in pstorefs wouldtrigger the dput() double-drop warning:  WARNING: CPU: 0 PID: 2569 at fs/dcache.c:762 dput.part.0+0x3f3/0x410Using the combo of d_drop()/dput() (as mentioned inDocumentation/filesystems/vfs.rst) isn&#39;t the right approach here, andleads to the reference counting problem seen above. Use d_invalidate()and update the code to not bother checking for error codes that cannever happen.---(CVE-2024-27389)In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Fixed overflow check in mi_enum_attr()(CVE-2024-27407)In the Linux kernel, the following vulnerability has been resolved:netrom: Fix data-races around sysctl_net_busy_readWe need to protect the reader reading the sysctl value because thevalue can be changed concurrently.(CVE-2024-27419)Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27426)Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-27427)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() beforedropping kvm-&gt;lock to fix use-after-free issues where region and/or itsarray 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 &#34;obvious&#34; alternative of using local variables doesn&#39;t fullyresolve the bug, as region-&gt;pages is also dynamically allocated.  I.e. theregion structure itself would be fine, but region-&gt;pages could be freed.Flushing multiple pages under kvm-&gt;lock is unfortunate, but the entireflow is a rare slow path, and the manual flush is only needed on CPUs thatlack coherency for encrypted memory.(CVE-2024-35791)In the Linux kernel, the following vulnerability has been resolved:x86/fpu: Keep xfd_state in sync with MSR_IA32_XFDCommit 672365477ae8 (&#34;x86/fpu: Update XFD state where required&#34;) andcommit 8bf26758ca96 (&#34;x86/fpu: Add XFD state to fpstate&#34;) introduced aper CPU variable xfd_state to keep the MSR_IA32_XFD value cached, inorder to avoid unnecessary writes to the MSR.On CPU hotplug MSR_IA32_XFD is reset to the init_fpstate.xfd, whichwipes out any stale state. But the per CPU cached xfd value is notreset, which brings them out of sync.As a consequence a subsequent xfd_update_state() might fail to updatethe MSR which in turn can result in XRSTOR raising a #NM in kernelspace, which crashes the kernel.To fix this, introduce xfd_set_state() to write xfd_state togetherwith MSR_IA32_XFD, and use it in all places that set MSR_IA32_XFD.(CVE-2024-35801)In the Linux kernel, the following vulnerability has been resolved:dm snapshot: fix lockup in dm_exception_table_exitThere was reported lockup when we exit a snapshot with many exceptions.Fix this by adding &#34;cond_resched&#34; to the loop that frees the exceptions.(CVE-2024-35805)In the Linux kernel, the following vulnerability has been resolved:soc: fsl: qbman: Always disable interrupts when taking cgr_locksmp_call_function_single disables IRQs when executing the callback. Toprevent deadlocks, we must disable IRQs when taking cgr_lock elsewhere.This is already done by qman_update_cgr and qman_delete_cgr; fix theother lockers.(CVE-2024-35806)In the Linux kernel, the following vulnerability has been resolved:LoongArch: Define the __io_aw() hook as mmiowb()Commit fb24ea52f78e0d595852e (&#34;drivers: Remove explicit invocations ofmmiowb()&#34;) remove all mmiowb() in drivers, but it says:&#34;NOTE: mmiowb() has only ever guaranteed ordering in conjunction withspin_unlock(). However, pairing each mmiowb() removal in this patch withthe corresponding call to spin_unlock() is not at all trivial, so thereis a small chance that this change may regress any drivers incorrectlyrelying on mmiowb() to order MMIO writes between CPUs using lock-freesynchronisation.&#34;The mmio in radeon_ring_commit() is protected by a mutex rather than aspinlock, but in the mutex fastpath it behaves similar to spinlock. Wecan add mmiowb() calls in the radeon driver but the maintainer says hedoesn&#39;t like such a workaround, and radeon is not the only example ofmutex 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, sowe 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 &#39;glxgears&#39; on weak orderingarchitectures such as LoongArch:radeon 0000:04:00.0: ring 0 stalled for more than 10324msecradeon 0000:04:00.0: ring 3 stalled for more than 10240msecradeon 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&#39;t update BO_VA (-35)radeon 0000:04:00.0: scheduling IB failed (-35).[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)radeon 0000:04:00.0: scheduling IB failed (-35).[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)radeon 0000:04:00.0: scheduling IB failed (-35).[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)radeon 0000:04:00.0: scheduling IB failed (-35).[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)radeon 0000:04:00.0: scheduling IB failed (-35).[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)radeon 0000:04:00.0: scheduling IB failed (-35).[drm:radeon_gem_va_ioctl [radeon]] *ERROR* Couldn&#39;t update BO_VA (-35)(CVE-2024-35818)In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: fix a double-free in arfs_create_groupsWhen `in` allocated by kvzalloc fails, arfs_create_groups will freeft-&gt;g and return an error. However, arfs_create_table, the only caller ofarfs_create_groups, will hold this error and call tomlx5e_destroy_flow_table, in which the ft-&gt;g will be freed again.(CVE-2024-35835)In the Linux kernel, the following vulnerability has been resolved:f2fs: compress: fix reserve_cblocks counting error when out of spaceWhen a file only needs one direct_node, performing the followingoperations will cause the file to be unrepairable:unisoc # ./f2fs_io compress test.apkunisoc #df -h | grep dm-48/dev/block/dm-48 112G 112G 1.2M 100% /dataunisoc # ./f2fs_io release_cblocks test.apk924unisoc # df -h | grep dm-48/dev/block/dm-48 112G 112G 4.8M 100% /dataunisoc # dd if=/dev/random of=file4 bs=1M count=33145728 bytes (3.0 M) copied, 0.025 s, 120 M/sunisoc # df -h | grep dm-48/dev/block/dm-48 112G 112G 1.8M 100% /dataunisoc # ./f2fs_io reserve_cblocks test.apkF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on deviceadb rebootunisoc # df -h  | grep dm-48/dev/block/dm-48             112G 112G   11M 100% /dataunisoc # ./f2fs_io reserve_cblocks test.apk0This is because the file has only one direct_node. After returningto -ENOSPC, reserved_blocks += ret will not be executed. As a result,the reserved_blocks at this time is still 0, which is not the realnumber of reserved blocks. Therefore, fsck cannot be set to repairthe 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% /dataunisoc # ./f2fs_io reserve_cblocks test.apkF2FS_IOC_RESERVE_COMPRESS_BLOCKS failed: No space left on deviceadb reboot then fsck will be executedunisoc # df -h  | grep dm-48/dev/block/dm-48             112G 112G   11M 100% /dataunisoc # ./f2fs_io reserve_cblocks test.apk924(CVE-2024-35844)In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: dbg-tlv: ensure NUL terminationThe iwl_fw_ini_debug_info_tlv is used as a string, so we mustensure the string is terminated correctly before using it.(CVE-2024-35845)In the Linux kernel, the following vulnerability has been resolved:eeprom: at24: fix memory corruption race conditionIf the eeprom is not accessible, an nvmem device will be registered, theread will fail, and the device will be torn down. If another driveraccesses the nvmem device after the teardown, it will referenceinvalid memory.Move the failure point before registering the nvmem device.(CVE-2024-35848)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() canconcurrent with __nft_flowtable_type_get() within nf_tables_newflowtable().And thhere is not any protection when iterate over nf_tables_flowtableslist in __nft_flowtable_type_get(). Therefore, there is pertentialdata-race of nf_tables_flowtables list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_flowtables listin __nft_flowtable_type_get(), and use rcu_read_lock() in the callernft_flowtable_type_get() to protect the entire type query process.(CVE-2024-35898)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 onoverflow. It is necessary to prevent division by zero like infb_var_to_videomode().Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35922)In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Fix possible memory leak in lpfc_rcv_padisc()The call to lpfc_sli4_resume_rpi() in lpfc_rcv_padisc() may return anunsuccessful status.  In such cases, the elsiocb is not issued, thecompletion is not called, and thus the elsiocb resource is leaked.Check return value after calling lpfc_sli4_resume_rpi() and conditionallyrelease the elsiocb resource.(CVE-2024-35930)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&#39;s  impossible to find a chunk item there due to alignment and size  constraints(CVE-2024-35936)In the Linux kernel, the following vulnerability has been resolved:pstore/zone: Add a null pointer check to the psz_kmsg_readkasprintf() returns a pointer to dynamically allocated memorywhich can be NULL upon failure. Ensure the allocation was successfulby checking the pointer validity.(CVE-2024-35940)In the Linux kernel, the following vulnerability has been resolved:xsk: validate user input for XDP_{UMEM|COMPLETION}_FILL_RINGsyzbot 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:1420Read of size 4 at addr ffff888028c6cde3 by task syz-executor.0/7549CPU: 0 PID: 7549 Comm: syz-executor.0 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call 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/0x75RIP: 0033:0x7fb40587de69Code: 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 48RSP: 002b:00007fb40665a0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 00007fb4059abf80 RCX: 00007fb40587de69RDX: 0000000000000005 RSI: 000000000000011b RDI: 0000000000000006RBP: 00007fb4058ca47a R08: 0000000000000002 R09: 0000000000000000R10: 0000000020001980 R11: 0000000000000246 R12: 0000000000000000R13: 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/0x75The buggy address belongs to the object at ffff888028c6cde0 which belongs to the cache kmalloc-8 of size 8The 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:0x28c6canon flags: 0xfff00000000800(slab|node=0|zone=1|lastcpupid=0x7ff)page_type: 0xffffffff()raw: 00fff00000000800 ffff888014c41280 0000000000000000 dead000000000001raw: ffff888028c6c9c0 0000000080800057 00000001ffffffff 0000000000000000page dumped because: kasan: bad access detectedpage_owner tracks the page as allocatedpage 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-2024-35976)In the Linux kernel, the following vulnerability has been resolved:HID: i2c-hid: remove I2C_HID_READ_PENDING flag to prevent lock-upThe flag I2C_HID_READ_PENDING is used to serialize I2C operations.However, this is not necessary, because I2C core already has its ownlocking for that.More importantly, this flag can cause a lock-up: if the flag is set ini2c_hid_xfer() and an interrupt happens, the interrupt handler(i2c_hid_irq) will check this flag and return immediately without doinganything, then the interrupt handler will be invoked again in aninfinite loop.Since interrupt handler is an RT task, it takes over the CPU and theflag-clearing task never gets scheduled, thus we have a lock-up.Delete this unnecessary flag.(CVE-2024-35997)In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix incorrect list API usageBoth the function that migrates all the chunks within a region and thefunction that migrates all the entries within a chunk calllist_first_entry() on the respective lists without checking that thelists are not empty. This is incorrect usage of the API, which leads tothe following warning [1].Fix by returning if the lists are empty as there is nothing to migratein 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 #39Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 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-36006)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.77.0.157.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.77.0.157.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.77.0.157.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1683</id>
          <title>An update for libvirt is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-05-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4418" id="CVE-2024-4418" title="CVE-2024-4418" type="cve"></reference>
          </references>
          <description>A race condition leading to a stack use-after-free flaw was found in libvirt. Due to a bad assumption in the virNetClientIOEventLoop() method, the `data` pointer to a stack-allocated virNetClientIOEventData structure ended up being used in the virNetClientIOEventFD callback while the data pointer&#39;s stack frame was concurrently being &#34;freed&#34; when returning from virNetClientIOEventLoop(). The &#39;virtproxyd&#39; daemon can be used to trigger requests. If libvirt is configured with fine-grained access control, this issue, in theory, allows a user to escape their otherwise limited access. This flaw allows a local, unprivileged user to access virtproxyd without authenticating. Remote users would need to authenticate before they could access it.(CVE-2024-4418)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libvirt-daemon-config-nwfilter" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-nwfilter-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-nss" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-nss-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-disk" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-disk-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-network" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-network-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-bash-completion" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-bash-completion-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-devel" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-devel-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-iscsi" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-client" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-client-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-docs" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-docs-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-kvm" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-kvm-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-config-network" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-network-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-qemu" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-qemu-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-mpath" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-mpath-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-interface" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-interface-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-core" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-core-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-gluster" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-gluster-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-secret" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-secret-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-qemu" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-qemu-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-admin" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-admin-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-libs" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-libs-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-lock-sanlock" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-lock-sanlock-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-wireshark" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-wireshark-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-debuginfo" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debuginfo-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-logical" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-logical-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-iscsi-direct" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-scsi" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-scsi-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-debugsource" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debugsource-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-nwfilter" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nwfilter-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-nodedev" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nodedev-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-rbd" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-rbd-6.2.0-64.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-client" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-client-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-network" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-network-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-devel" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-devel-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-logical" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-logical-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-docs" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-docs-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-debuginfo" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debuginfo-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-debugsource" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debugsource-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-libs" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-libs-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-mpath" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-mpath-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-iscsi" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-nodedev" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nodedev-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-scsi" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-scsi-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-lock-sanlock" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-lock-sanlock-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-nss" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-nss-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-admin" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-admin-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-config-network" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-network-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-kvm" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-kvm-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-bash-completion" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-bash-completion-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-rbd" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-rbd-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-qemu" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-qemu-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-qemu" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-qemu-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-config-nwfilter" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-nwfilter-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-disk" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-disk-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-wireshark" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-wireshark-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-core" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-core-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-nwfilter" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nwfilter-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-gluster" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-gluster-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-interface" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-interface-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-iscsi-direct" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-secret" release="64.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-secret-6.2.0-64.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1685</id>
          <title>An update for openjdk-17 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20918" id="CVE-2024-20918" title="CVE-2024-20918" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20932" id="CVE-2024-20932" title="CVE-2024-20932" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21012" id="CVE-2024-21012" title="CVE-2024-21012" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"></reference>
          </references>
          <description>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-20918)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-20932)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-21012)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-21068)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-headless" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-headless-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-demo-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-demo-slowdebug-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-devel" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-devel-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-jmods-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-jmods-slowdebug-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-devel-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-devel-slowdebug-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-debuginfo" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-debuginfo-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-javadoc" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-javadoc-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-jmods" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-jmods-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-slowdebug-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-javadoc-zip" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-javadoc-zip-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-headless-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-headless-slowdebug-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-src-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-src-slowdebug-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-src" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-src-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-debugsource" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-debugsource-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-17-openjdk-demo" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-demo-17.0.11.9-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-devel-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-devel-slowdebug-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-demo" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-demo-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-jmods-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-jmods-slowdebug-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-slowdebug-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-headless-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-headless-slowdebug-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-src-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-src-slowdebug-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-debugsource" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-debugsource-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-devel" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-devel-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-jmods" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-jmods-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-javadoc-zip" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-javadoc-zip-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-javadoc" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-javadoc-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-headless" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-headless-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-src" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-src-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-demo-slowdebug" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-demo-slowdebug-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-17-openjdk-debuginfo" release="1.oe2203sp1" version="17.0.11.9">
                         <filename>java-17-openjdk-debuginfo-17.0.11.9-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1688</id>
          <title>An update for runc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-05-31"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3154" id="CVE-2024-3154" title="CVE-2024-3154" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-3154)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="docker-runc" release="25.oe2203sp1" version="1.1.3">
                         <filename>docker-runc-1.1.3-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="docker-runc" release="25.oe2203sp1" version="1.1.3">
                         <filename>docker-runc-1.1.3-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1689</id>
          <title>An update for libva is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39929" id="CVE-2023-39929" title="CVE-2023-39929" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-39929)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libva-debuginfo" release="1.oe2203sp1" version="2.20.0">
                         <filename>libva-debuginfo-2.20.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libva" release="1.oe2203sp1" version="2.20.0">
                         <filename>libva-2.20.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libva-devel" release="1.oe2203sp1" version="2.20.0">
                         <filename>libva-devel-2.20.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libva-debugsource" release="1.oe2203sp1" version="2.20.0">
                         <filename>libva-debugsource-2.20.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libva-debuginfo" release="1.oe2203sp1" version="2.20.0">
                         <filename>libva-debuginfo-2.20.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libva-debugsource" release="1.oe2203sp1" version="2.20.0">
                         <filename>libva-debugsource-2.20.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libva-devel" release="1.oe2203sp1" version="2.20.0">
                         <filename>libva-devel-2.20.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libva" release="1.oe2203sp1" version="2.20.0">
                         <filename>libva-2.20.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1693</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47370" id="CVE-2021-47370" title="CVE-2021-47370" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47489" id="CVE-2021-47489" title="CVE-2021-47489" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48689" id="CVE-2022-48689" title="CVE-2022-48689" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52654" id="CVE-2023-52654" title="CVE-2023-52654" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52655" id="CVE-2023-52655" title="CVE-2023-52655" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52669" id="CVE-2023-52669" title="CVE-2023-52669" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52699" id="CVE-2023-52699" title="CVE-2023-52699" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52703" id="CVE-2023-52703" title="CVE-2023-52703" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52730" id="CVE-2023-52730" title="CVE-2023-52730" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52735" id="CVE-2023-52735" title="CVE-2023-52735" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52736" id="CVE-2023-52736" title="CVE-2023-52736" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52750" id="CVE-2023-52750" title="CVE-2023-52750" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52752" id="CVE-2023-52752" title="CVE-2023-52752" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52759" id="CVE-2023-52759" title="CVE-2023-52759" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52774" id="CVE-2023-52774" title="CVE-2023-52774" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52789" id="CVE-2023-52789" title="CVE-2023-52789" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52795" id="CVE-2023-52795" title="CVE-2023-52795" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52802" id="CVE-2023-52802" title="CVE-2023-52802" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52804" id="CVE-2023-52804" title="CVE-2023-52804" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52805" id="CVE-2023-52805" title="CVE-2023-52805" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52808" id="CVE-2023-52808" title="CVE-2023-52808" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52814" id="CVE-2023-52814" title="CVE-2023-52814" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52818" id="CVE-2023-52818" title="CVE-2023-52818" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52819" id="CVE-2023-52819" title="CVE-2023-52819" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52826" id="CVE-2023-52826" title="CVE-2023-52826" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52832" id="CVE-2023-52832" title="CVE-2023-52832" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52836" id="CVE-2023-52836" title="CVE-2023-52836" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52845" id="CVE-2023-52845" title="CVE-2023-52845" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52858" id="CVE-2023-52858" title="CVE-2023-52858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52859" id="CVE-2023-52859" title="CVE-2023-52859" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52864" id="CVE-2023-52864" title="CVE-2023-52864" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52871" id="CVE-2023-52871" title="CVE-2023-52871" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52878" id="CVE-2023-52878" title="CVE-2023-52878" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26833" id="CVE-2024-26833" title="CVE-2024-26833" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26877" id="CVE-2024-26877" title="CVE-2024-26877" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26934" id="CVE-2024-26934" title="CVE-2024-26934" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27020" id="CVE-2024-27020" title="CVE-2024-27020" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27401" id="CVE-2024-27401" title="CVE-2024-27401" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27413" id="CVE-2024-27413" title="CVE-2024-27413" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35822" id="CVE-2024-35822" title="CVE-2024-35822" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35823" id="CVE-2024-35823" title="CVE-2024-35823" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35840" id="CVE-2024-35840" title="CVE-2024-35840" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35877" id="CVE-2024-35877" title="CVE-2024-35877" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35939" id="CVE-2024-35939" title="CVE-2024-35939" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35950" id="CVE-2024-35950" title="CVE-2024-35950" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35956" id="CVE-2024-35956" title="CVE-2024-35956" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35958" id="CVE-2024-35958" title="CVE-2024-35958" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35960" id="CVE-2024-35960" title="CVE-2024-35960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35978" id="CVE-2024-35978" title="CVE-2024-35978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35984" id="CVE-2024-35984" title="CVE-2024-35984" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35995" id="CVE-2024-35995" title="CVE-2024-35995" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36000" id="CVE-2024-36000" title="CVE-2024-36000" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36015" id="CVE-2024-36015" title="CVE-2024-36015" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36940" id="CVE-2024-36940" title="CVE-2024-36940" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:mptcp: ensure tx skbs always have the MPTCP extDue to signed/unsigned comparison, the expression:&#x9;info-&gt;size_goal - skb-&gt;len &gt; 0evaluates to true when the size goal is smaller than theskb size. That results in lack of tx cache refill, so thatthe skb allocated by the core TCP code lacks the requiredMPTCP 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:1366Modules linked in:CPU: 1 PID: 810 Comm: syz-executor.4 Not tainted 5.14.0-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011RIP: 0010:mptcp_sendmsg_frag+0x1362/0x1bc0 net/mptcp/protocol.c:1366Code: 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 e9RSP: 0018:ffffc9000531f6a0 EFLAGS: 00010216RAX: 000000000000697f RBX: 0000000000000000 RCX: ffffc90012107000RDX: 0000000000040000 RSI: ffffffff88eac9e2 RDI: 0000000000000003RBP: ffff888078b15780 R08: 0000000000000000 R09: 0000000000000000R10: ffffffff88eac017 R11: 0000000000000000 R12: ffff88801de0a280R13: 0000000000006b58 R14: ffff888066278280 R15: ffff88803c2fe9c0FS:  00007fd9f866e700(0000) GS:ffff8880b9d00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007faebcb2f718 CR3: 00000000267cb000 CR4: 00000000001506e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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/0xaeRIP: 0033:0x4665f9Code: 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 48RSP: 002b:00007fd9f866e188 EFLAGS: 00000246 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 000000000056c038 RCX: 00000000004665f9RDX: 00000000000e7b78 RSI: 0000000020000000 RDI: 0000000000000003RBP: 00000000004bfcc4 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 000000000056c038R13: 0000000000a9fb1f R14: 00007fd9f866e300 R15: 0000000000022000Fix the issue rewriting the relevant expression to avoidsign-related problems - note: size_goal is always &gt;= 0.Additionally, ensure that the skb in the tx cache always carriesthe relevant extension.(CVE-2021-47370)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix even more out of bound writes from debugfsCVE-2021-42327 was fixed by:commit f23750b5b3d98653b31d4469592935ef6364ad67Author: Thelford Williams &lt;tdwilliamsiv@gmail.com&gt;Date:   Wed Oct 13 16:04:13 2021 -0400    drm/amdgpu: fix out of bounds writebut amdgpu_dm_debugfs.c contains more of the same issue so fix theremaining ones.v2:&#x9;* Add missing fix in dp_max_bpc_write (Harry Wentland)(CVE-2021-47489)In the Linux kernel, the following vulnerability has been resolved:tcp: TX zerocopy should not sense pfmemalloc statusWe got a recent syzbot report [1] showing a possible misuseof 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 givefalse 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 (&#34;net: introduce__skb_fill_page_desc_noacc&#34;) as a prereq.Race is more probable after commit c07aea3ef4d4(&#34;mm: add a signature in struct page&#34;) because page_is_pfmemalloc()is now using low order bit from page-&gt;lru.next, which can changemore often than page-&gt;index.Low order bit should never be set for lru.next (when used as an anchorin 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_fragwrite 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:228folio_batch_move_lru+0x1e1/0x2a0 mm/swap.c:246folio_batch_add_and_move mm/swap.c:263 [inline]folio_add_lru+0xf1/0x140 mm/swap.c:490filemap_add_folio+0xf8/0x150 mm/filemap.c:948__filemap_get_folio+0x510/0x6d0 mm/filemap.c:1981pagecache_get_page+0x26/0x190 mm/folio-compat.c:104grab_cache_page_write_begin+0x2a/0x30 mm/folio-compat.c:116ext4_da_write_begin+0x2dd/0x5f0 fs/ext4/inode.c:2988generic_perform_write+0x1d4/0x3f0 mm/filemap.c:3738ext4_buffered_write_iter+0x235/0x3e0 fs/ext4/file.c:270ext4_file_write_iter+0x2e3/0x1210call_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:578ksys_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:640do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdread 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:1018do_tcp_sendpages+0x3e8/0xaf0 net/ipv4/tcp.c:1075tcp_sendpage_locked net/ipv4/tcp.c:1140 [inline]tcp_sendpage+0x89/0xb0 net/ipv4/tcp.c:1150inet_sendpage+0x7f/0xc0 net/ipv4/af_inet.c:833kernel_sendpage+0x184/0x300 net/socket.c:3561sock_sendpage+0x5a/0x70 net/socket.c:1054pipe_to_sendpage+0x128/0x160 fs/splice.c:361splice_from_pipe_feed fs/splice.c:415 [inline]__splice_from_pipe+0x222/0x4d0 fs/splice.c:559splice_from_pipe fs/splice.c:594 [inline]generic_splice_sendpage+0x89/0xc0 fs/splice.c:743do_splice_from fs/splice.c:764 [inline]direct_splice_actor+0x80/0xa0 fs/splice.c:931splice_direct_to_actor+0x305/0x620 fs/splice.c:886do_splice_direct+0xfb/0x180 fs/splice.c:974do_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:1303do_syscall_x64 arch/x86/entry/common.c:50 [inline]do_syscall_64+0x2b/0x70 arch/x86/entry/common.c:80entry_SYSCALL_64_after_hwframe+0x63/0xcdvalue changed: 0x0000000000000000 -&gt; 0xffffea0004a1d288Reported by Kernel Concurrency Sanitizer on:CPU: 1 PID: 18611 Comm: syz-executor.4 Not tainted 6.0.0-rc2-syzkaller-00248-ge022620b5d05-dirty #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/22/2022(CVE-2022-48689)In the Linux kernel, the following vulnerability has been resolved:io_uring/af_unix: disable sending io_uring over socketsFile reference cycles have caused lots of problems for io_uringin the past, and it still doesn&#39;t work exactly right and races withunix_stream_read_generic(). The safest fix would be to completelydisallow sending io_uring files via sockets via SCM_RIGHT, so thereare no possible cycles invloving registered files and thus renderingSCM accounting on the io_uring side unnecessary.(CVE-2023-52654)In the Linux kernel, the following vulnerability has been resolved:usb: aqc111: check packet for fixup for true limitIf a device sends a packet that is inbetween 0and sizeof(u64) the value passed to skb_trim()as length will wrap around ending up as some verylarge value.The driver will then proceed to parse the headerlocated at that position, which will either oops orprocess some random value.The fix is to check against sizeof(u64) rather than0, which the driver currently does. The issue existssince the introduction of the driver.(CVE-2023-52655)In the Linux kernel, the following vulnerability has been resolved:crypto: s390/aes - Fix buffer overread in CTR modeWhen processing the last block, the s390 ctr code will always reada whole block, even if there isn&#39;t a whole block of data left.  Fixthis by using the actual length left and copy it into a buffer firstfor processing.(CVE-2023-52669)In the Linux kernel, the following vulnerability has been resolved:sysv: don&#39;t call sb_bread() with pointers_lock heldsyzbot is reporting sleep in atomic context in SysV filesystem [1], forsb_bread() is called with rw_spinlock held.A &#34;write_lock(&amp;pointers_lock) =&gt; read_lock(&amp;pointers_lock) deadlock&#34; bugand a &#34;sb_bread() with write_lock(&amp;pointers_lock)&#34; bug were introduced by&#34;Replace BKL for chain locking with sysvfs-private rwlock&#34; in Linux 2.5.12.Then, &#34;[PATCH] err1-40: sysvfs locking fix&#34; in Linux 2.6.8 fixed theformer bug by moving pointers_lock lock to the callers, but insteadintroduced a &#34;sb_bread() with read_lock(&amp;pointers_lock)&#34; bug (which madethis 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 arevert of &#34;[PATCH] err1-40: sysvfs locking fix&#34; except that get_branch() from with find_shared() is called without write_lock(&amp;pointers_lock).(CVE-2023-52699)In the Linux kernel, the following vulnerability has been resolved:net/usb: kalmia: Don&#39;t pass act_len in usb_bulk_msg error pathsyzbot reported that act_len in kalmia_send_init_packet() isuninitialized when passing it to the first usb_bulk_msg error path. JiriPirko noted that it&#39;s pointless to pass it in the error path, and thatthe value that would be printed in the second error path would be thevalue of act_len from the first call to usb_bulk_msg.[1]With this in mind, let&#39;s just not pass act_len to the usb_bulk_msg errorpaths.1: https://lore.kernel.org/lkml/Y9pY61y1nwTuzMOa@nanopsycho/(CVE-2023-52703)In the Linux kernel, the following vulnerability has been resolved:mmc: sdio: fix possible resource leaks in some error pathsIf sdio_add_func() or sdio_init_func() fails, sdio_remove_func() cannot release the resources, because the sdio function is not presentedin these two cases, it won&#39;t call of_node_put() or put_device().To fix these leaks, make sdio_func_present() only control whetherdevice_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 &#39;card-&gt;dev&#39; isnot get, to avoid redundant put in sdio_free_func_cis(), move theget_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 thefollowing leak reports, after this fix, the leak is gone.unreferenced object 0xffff888112514000 (size 2048):  comm &#34;kworker/3:2&#34;, 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 &#34;kworker/3:2&#34;, 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-52730)In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Don&#39;t let sock_map_{close,destroy,unhash} call itselfsock_map proto callbacks should never call themselves by design. Protectagainst bugs like [1] and break out of the recursive loop to avoid a stackoverflow in favor of a resource leak.[1] https://lore.kernel.org/all/00000000000073b14905ef2e7401@google.com/(CVE-2023-52735)In the Linux kernel, the following vulnerability has been resolved:ALSA: hda: Do not unset preset when cleaning up codecSeveral functions that take part in codec&#39;s initialization and removalare re-used by ASoC codec drivers implementations. Drivers mimic thebehavior of hda_codec_driver_probe/remove() found insound/pci/hda/hda_bind.c with their component-&gt;probe/remove() instead.One of the reasons for that is the expectation ofsnd_hda_codec_device_new() to receive a valid pointer to an instance ofstruct snd_card. This expectation can be met only once sound cardcomponents probing commences.As ASoC sound card may be unbound without codec device being actuallyremoved from the system, unsetting -&gt;preset insnd_hda_codec_cleanup_for_unbind() interferes with module unload -&gt; loadscenario causing null-ptr-deref. Preset is assigned only once, duringdevice/driver matching whereas ASoC codec driver&#39;s module reloading mayoccur several times throughout the lifetime of an audio stack.(CVE-2023-52736)In the Linux kernel, the following vulnerability has been resolved:arm64: Restrict CPU_BIG_ENDIAN to GNU as or LLVM IAS 15.x or newerPrior to LLVM 15.0.0, LLVM&#39;s integrated assembler would incorrectlybyte-swap NOP when compiling for big-endian, and the resulting series ofbytes happened to match the encoding of FNMADD S21, S30, S0, S0.This went unnoticed until commit:  34f66c4c4d5518c1 (&#34;arm64: Use a positive cpucap for FP/SIMD&#34;)Prior to that commit, the kernel would always enable the use of FPSIMDearly in boot when __cpu_setup() initialized CPACR_EL1, and so usage ofFNMADD within the kernel was not detected, but could result in thecorruption of user or kernel FPSIMD state.After that commit, the instructions happen to trap during boot prior toFPSIMD 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/0xc4Restrict CONFIG_CPU_BIG_ENDIAN to a known good assembler, which iseither GNU as or LLVM&#39;s IAS 15.0.0 and newer, which contains the linkedcommit.(CVE-2023-52750)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/DebugDatawhile 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-2023-52752)In the Linux kernel, the following vulnerability has been resolved:gfs2: ignore negated quota changesWhen lots of quota changes are made, there may be cases in which aninode&#39;s quota information is increased and then decreased, such as whenblocks are added to a file, then deleted from it. If the timing isright, function do_qc can add pending quota changes to a transaction,then later, another call to do_qc can negate those changes, resultingin a net gain of 0. The quota_change information is recorded in the qcbuffer (and qd element of the inode as well). The buffer is added to thetransaction by the first call to do_qc, but a subsequent call changesthe value from non-zero back to zero. At that point it&#39;s too late toremove the buffer_head from the transaction. Later, when the quota synccode is called, the zero-change qd element is discovered and flagged asan assert warning. If the fs is mounted with errors=panic, the kernelwill panic.This is usually seen when files are truncated and the quota changes arenegated by punch_hole/truncate which uses gfs2_quota_hold andgfs2_quota_unhold rather than block allocations that use gfs2_quota_lockand gfs2_quota_unlock which automatically do quota sync.This patch solves the problem by adding a check to qd_check_sync suchthat net-zero quota changes already added to the transaction are nolonger deemed necessary to be synced, and skipped.In this case references are taken for the qd and the slot from do_qcso those need to be put. The normal sequence of events for a normalnon-zero quota change is as follows:gfs2_quota_change   do_qc      qd_hold      slot_holdLater, 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&#x9;    lockref_put_or_lock   qd_unlock      qd_put         lockref_put_or_lockIn the net-zero change case, we add a check to qd_check_sync so it putsthe qd and slot references acquired in gfs2_quota_change and skip theunneeded sync.(CVE-2023-52759)In the Linux kernel, the following vulnerability has been resolved:s390/dasd: protect device queue against concurrent accessIn dasd_profile_start() the amount of requests on the device queue arecounted. The access to the device queue is unprotected againstconcurrent access. With a lot of parallel I/O, especially with aliasdevices enabled, the device queue can change while dasd_profile_start()is accessing the queue. In the worst case this leads to a kernel panicdue to incorrect pointer accesses.Fix this by taking the device lock before accessing the queue andcounting the requests. Additionally the check for a valid profile datapointer can be done earlier to avoid unnecessary locking in a hot path.(CVE-2023-52774)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 itfails in order to avoid NULL pointer dereference.(CVE-2023-52789)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 callsida_simple_remove() and frees &#34;v&#34;.  So this call toida_simple_remove() is a use after free and a double free.(CVE-2023-52795)In the Linux kernel, the following vulnerability has been resolved:iio: adc: stm32-adc: harden against NULL pointer deref in stm32_adc_probe()of_match_device() may fail and returns a NULL pointer.In practice there is no known reasonable way to trigger this, butin case one is added in future, harden the code by adding the check(CVE-2023-52802)In the Linux kernel, the following vulnerability has been resolved:fs/jfs: Add validity check for db_maxag and db_agprefBoth db_maxag and db_agpref are used as the index of thedb_agfree array, but there is currently no validity check fordb_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:20index 7936 is out of range for type &#39;atomic_t[128]&#39;Add checking that the values of db_maxag and db_agpref are validindexes for the db_agfree array.(CVE-2023-52804)In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in diAllocCurrently there is not check against the agno of the iag whileallocating new inodes to avoid fragmentation problem. Added the checkwhich is required.(CVE-2023-52805)In the Linux kernel, the following vulnerability has been resolved:scsi: hisi_sas: Set debugfs_dir pointer to NULL after removing debugfsIf init debugfs failed during device registration due to memory allocationfailure, debugfs_remove_recursive() is called, after which debugfs_dir isnot set to NULL. debugfs_remove_recursive() will be called again duringdevice 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/0xcTo fix this, set debugfs_dir to NULL after debugfs_remove_recursive().(CVE-2023-52808)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix potential null pointer derefernceThe amdgpu_ras_get_context may return NULL if devicenot support ras feature, so add check before using.(CVE-2023-52814)In the Linux kernel, the following vulnerability has been resolved:drm/amd: Fix UBSAN array-index-out-of-bounds for SMU7For pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52818)In the Linux kernel, the following vulnerability has been resolved:drm/amd: Fix UBSAN array-index-out-of-bounds for Polaris and TongaFor pptable structs that use flexible array sizes, use flexible arrays.(CVE-2023-52819)In the Linux kernel, the following vulnerability has been resolved:drm/panel/panel-tpo-tpg110: fix a possible null pointer dereferenceIn tpg110_get_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52826)In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: don&#39;t return unset power in ieee80211_get_tx_power()We can get a UBSAN warning if ieee80211_get_tx_power() returns theINT_MIN value mac80211 internally uses for &#34;unset power level&#34;. UBSAN: signed-integer-overflow in net/wireless/nl80211.c:3816:5 -2147483648 * 100 cannot be represented in type &#39;int&#39; 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 indicatethat no data is available.(CVE-2023-52832)In the Linux kernel, the following vulnerability has been resolved:locking/ww_mutex/test: Fix potential workqueue corruptionIn some cases running with the test-ww_mutex code, I was seeingodd behavior where sometimes it seemed flush_workqueue wasreturning before all the work threads were finished.Often this would cause strange crashes as the mutexes would befreed while they were being used.Looking at the code, there is a lifetime problem as thecontrolling thread that spawns the work allocates the&#34;struct stress&#34; structures that are passed to the workqueuethreads. 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 stressstruct. Which means the work_struct is freed before the workthread returns and while flush_workqueue is waiting.It seems like a better idea to have the controlling threadboth allocate and free the stress structures, so that we canbe sure we don&#39;t corrupt the workqueue by freeing the structureprematurely.So this patch reworks the test to do so, and with this changeI no longer see the early flush_workqueue returns.(CVE-2023-52836)In the Linux kernel, the following vulnerability has been resolved:tipc: Change nla_policy for bearer-related names to NLA_NUL_STRINGsyzbot 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/0xcdUninit 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/0xcdTIPC bearer-related names including link names must be null-terminatedstrings. If a link name which is not null-terminated is passed throughnetlink, strstr() and similar functions can cause buffer overrun. Thiscauses the above issue.This patch changes the nla_policy for bearer-related names from NLA_STRINGto NLA_NUL_STRING. This resolves the issue by ensuring that onlynull-terminated strings are accepted as bearer-related names.syzbot reported similar uninit-value issue related to bearer names [2]. Theroot cause of this issue is that a non-null-terminated bearer name waspassed. This patch also resolved this issue.(CVE-2023-52845)In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: clk-mt7629: Add check for mtk_alloc_clk_dataAdd the check for the return value of mtk_alloc_clk_data() in order toavoid NULL pointer dereference.(CVE-2023-52858)In the Linux kernel, the following vulnerability has been resolved:perf: hisi: Fix use-after-free when register pmu failsWhen we fail to register the uncore pmu, the pmu context may not beenallocated. The error handing will call cpuhp_state_remove_instance()to call uncore pmu offline callback, which migrate the pmu context.Since that&#39;s liable to lead to some kind of use-after-free.Use cpuhp_state_remove_instance_nocalls() instead ofcpuhp_state_remove_instance() so that the notifiers don&#39;t execute afterthe PMU device has been failed to register.(CVE-2023-52859)In the Linux kernel, the following vulnerability has been resolved:platform/x86: wmi: Fix opening of char deviceSince commit fa1f68db6ca7 (&#34;drivers: misc: pass miscdevice pointer viafile private data&#34;), the miscdevice stores a pointer to itself insidefilp-&gt;private_data, which means that private_data will not be NULL whenwmi_char_open() is called. This might cause memory corruption shouldwmi_char_open() be unable to find its driver, something which canhappen when the associated WMI device is deleted in wmi_free_devices().Fix the problem by using the miscdevice pointer to retrieve the WMIdevice data associated with a char device using container_of(). Thisalso avoids wmi_char_open() picking a wrong WMI device bound to adriver with the same name as the original driver.(CVE-2023-52864)In the Linux kernel, the following vulnerability has been resolved:soc: qcom: llcc: Handle a second device without data corruptionUsually there is only one llcc device. But if there were a second, evena failed probe call would modify the global drv_data pointer. So checkif drv_data is valid before overwriting it.(CVE-2023-52871)In the Linux kernel, the following vulnerability has been resolved:can: dev: can_put_echo_skb(): don&#39;t crash kernel if can_priv::echo_skb is accessed out of boundsIf the &#34;struct can_priv::echoo_skb&#34; is accessed out of bounds, thiswould cause a kernel crash. Instead, issue a meaningful warningmessage and return with an error.(CVE-2023-52878)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix memory leak in dm_sw_fini()After destroying dmub_srv, the memory associated with it isnot freed, causing a memory leak:unreferenced object 0xffff896302b45800 (size 1024):  comm &#34;(udev-worker)&#34;, pid 222, jiffies 4294894636  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 6265fd77):    [&lt;ffffffff993495ed&gt;] kmalloc_trace+0x29d/0x340    [&lt;ffffffffc0ea4a94&gt;] dm_dmub_sw_init+0xb4/0x450 [amdgpu]    [&lt;ffffffffc0ea4e55&gt;] dm_sw_init+0x15/0x2b0 [amdgpu]    [&lt;ffffffffc0ba8557&gt;] amdgpu_device_init+0x1417/0x24e0 [amdgpu]    [&lt;ffffffffc0bab285&gt;] amdgpu_driver_load_kms+0x15/0x190 [amdgpu]    [&lt;ffffffffc0ba09c7&gt;] amdgpu_pci_probe+0x187/0x4e0 [amdgpu]    [&lt;ffffffff9968fd1e&gt;] local_pci_probe+0x3e/0x90    [&lt;ffffffff996918a3&gt;] pci_device_probe+0xc3/0x230    [&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;ffffffff990012d1&gt;] do_one_initcall+0x41/0x300Fix this by freeing dmub_srv after destroying it.(CVE-2024-26833)In the Linux kernel, the following vulnerability has been resolved:crypto: xilinx - call finalize with bh disabledWhen calling crypto_finalize_request, BH should be disabled to avoidtriggering 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-26877)In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix deadlock in usb_deauthorize_interface()Among the attribute file callback routines indrivers/usb/core/sysfs.c, the interface_authorized_store() function isthe only one which acquires a device lock on an ancestor device: Itcalls usb_deauthorize_interface(), which locks the interface&#39;s parentUSB device.The will lead to deadlock if another process already owns that lockand tries to remove the interface, whether through a configurationchange or because the device has been disconnected.  As part of theremoval procedure, device_del() waits for all ongoing sysfs attributecallbacks to complete.  But usb_deauthorize_interface() can&#39;t completeuntil the device lock has been released, and the lock won&#39;t bereleased until the removal has finished.The mechanism provided by sysfs to prevent this kind of deadlock isto use the sysfs_break_active_protection() function, which tells sysfsnot 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-26934)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_expressionslist in __nft_expr_type_get(). Therefore, there is potential data-raceof nf_tables_expressions list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_expressionslist in __nft_expr_type_get(), and use rcu_read_lock() in the callernft_expr_type_get() to protect the entire type query process.(CVE-2024-27020)In the Linux kernel, the following vulnerability has been resolved:firewire: nosy: ensure user_length is taken into account when fetching packet contentsEnsure that packet_buffer_get respects the user_length provided. Ifthe length of the head packet exceeds the user_length, packet_buffer_getwill now return 0 to signify to the user that no data were readand a larger buffer size is required. Helps prevent user space overflows.(CVE-2024-27401)In the Linux kernel, the following vulnerability has been resolved:efi/capsule-loader: fix incorrect allocation sizegcc-14 notices that the allocation with sizeof(void) on 32-bit architecturesis not enough for a 64-bit phys_addr_t:drivers/firmware/efi/capsule-loader.c: In function &#39;efi_capsule_open&#39;:drivers/firmware/efi/capsule-loader.c:295:24: error: allocation of insufficient size &#39;4&#39; for type &#39;phys_addr_t&#39; {aka &#39;long long unsigned int&#39;} with size &#39;8&#39; [-Werror=alloc-size]  295 |         cap_info-&gt;phys = kzalloc(sizeof(void *), GFP_KERNEL);      |                        ^Use the correct type instead here.(CVE-2024-27413)In the Linux kernel, the following vulnerability has been resolved:usb: udc: remove warning when queue disabled epIt 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/0x104pc : usb_ep_queue+0x7c/0x104lr : fsg_main_thread+0x494/0x1b3cRoot 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 effortto fix warning, change WARN_ON_ONCE() in usb_ep_queue() to pr_debug().(CVE-2024-35822)In the Linux kernel, the following vulnerability has been resolved:vt: fix unicode buffer corruption when deleting charactersThis is the same issue that was fixed for the VGA text buffer in commit39cdb68c64d8 (&#34;vt: fix memory overlapping when deleting chars in thebuffer&#34;). The cure is also the same i.e. replace memcpy() with memmove()due to the overlaping buffers.(CVE-2024-35823)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 setin mptcp_parse_option()(CVE-2024-35840)In the Linux kernel, the following vulnerability has been resolved:x86/mm/pat: fix VM_PAT handling in COW mappingsPAT handling won&#39;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 anonfolios.  Reliably recovering the correct PFN and cachemode usingfollow_phys() from PTEs will not work in COW mappings.Using follow_phys(), we might just get the address+protection of the anonfolio (which is very wrong), or fail on swap/nonswap entries, failingfollow_phys() and triggering a WARN_ON_ONCE() in untrack_pfn() andtrack_pfn_copy(), not properly calling free_pfn_range().In free_pfn_range(), we either wouldn&#39;t call memtype_free() or would callit with the wrong range, possibly leaking memory.To fix that, let&#39;s update follow_phys() to refuse returning anon folios,and fallback to using the stored PFN inside vma-&gt;vm_pgoff for COW mappingsif we run into that.We will now properly handle untrack_pfn() with COW mappings, where wedon&#39;t need the cachemode.  We&#39;ll have to fail fork()-&gt;track_pfn_copy() ifthe first page was replaced by an anon folio, though: we&#39;d have to storethe 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 thatcase: 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(&#34;io_uring_setup&#34;);                 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(&#34;mmap&#34;);                 return 1;         }         /* We have at least one page. Let&#39;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-2024-35877)In the Linux kernel, the following vulnerability has been resolved:dma-direct: Leak pages on dma_set_decrypted() failureOn TDX it is possible for the untrusted host to causeset_memory_encrypted() or set_memory_decrypted() to fail such that anerror is returned and the resulting memory is shared. Callers need totake care to handle these errors to avoid returning decrypted (shared)memory to the page allocator, which could lead to functional or securityissues.DMA could free decrypted/shared pages if dma_set_decrypted() fails. Thisshould be a rare case. Just leak the pages in this case instead offreeing them.(CVE-2024-35939)In the Linux kernel, the following vulnerability has been resolved:drm/client: Fully protect modes[] with dev-&gt;mode_config.mutexThe modes[] array contains pointers to modes on the connectors&#39;mode lists, which are protected by dev-&gt;mode_config.mutex.Thus we need to extend modes[] the same protection or by thetime we use it the elements may already be pointing tofreed/reused memory.(CVE-2024-35950)In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix qgroup prealloc rsv leak in subvolume operationsCreate subvolume, create snapshot and delete subvolume all usebtrfs_subvolume_reserve_metadata() to reserve metadata for the changesdone to the parent subvolume&#39;s fs tree, which cannot be mediated in thenormal way via start_transaction. When quota groups (squota or qgroups)are enabled, this reserves qgroup metadata of type PREALLOC. Once theoperation is associated to a transaction, we convert PREALLOC toPERTRANS, which gets cleared in bulk at the end of the transaction.However, the error paths of these three operations were not implementingthis lifecycle correctly. They unconditionally converted the PREALLOC toPERTRANS in a generic cleanup step regardless of errors or whether theoperation was fully associated to a transaction or not. This resulted inerror paths occasionally converting this rsv to PERTRANS without callingrecord_root_in_trans successfully, which meant that unless that root gotrecorded in the transaction by some other thread, the end of thetransaction would not free that root&#39;s PERTRANS, leaking it. Ultimately,this resulted in hitting a WARN in CONFIG_BTRFS_DEBUG builds at unmountfor the leaked reservation.The fix is to ensure that every qgroup PREALLOC reservation observes thefollowing 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. Withoutit, generic/269 with squotas enabled at mkfs time would fail in ~5-10runs on my system. With this patch, it ran successfully 1000 times in arow.(CVE-2024-35956)In the Linux kernel, the following vulnerability has been resolved:net: ena: Fix incorrect descriptor free behaviorENA 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 instructionsThe ena_free_tx_bufs() cycles through all descriptors in a TX queueand unmaps + frees every descriptor that hasn&#39;t been acknowledged yetby the device (uncompleted TX transactions).The function assumes that the processed TX queue is necessarily fromthe 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, thedescriptors aren&#39;t freed correctly, leading to crashes.(CVE-2024-35958)In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Properly link new fs rules into the treePreviously, add_rule_fg would only add newly created rules from thehandle into the tree when they had a refcount of 1. On the other hand,create_flow_handle tries hard to find and reference already existingidentical rules instead of creating new ones.These two behaviors can result in a situation where create_flow_handle1) creates a new rule and references it, then2) 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 thetree, will have a NULL parent and root and will result in a crash whenthe flow group is deleted because del_sw_hw_rule, invoked on ruledeletion, assumes node-&gt;parent is != NULL.This happened in the wild, due to another bug related to incorrecthandling of duplicate pkt_reformat ids, which lead to the code increate_flow_handle incorrectly referencing a just-added rule in the sameflow handle, resulting in the problem described above. Full details areat [1].This patch changes add_rule_fg to add new rules without parents intothe tree, properly initializing them and avoiding the crash. This makesit more consistent with how rules are added to an FTE increate_flow_handle.(CVE-2024-35960)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: Fix memory leak in hci_req_sync_complete()In &#39;hci_req_sync_complete()&#39;, always free the previous syncrequest state before assigning reference to a new one.(CVE-2024-35978)In the Linux kernel, the following vulnerability has been resolved:i2c: smbus: fix NULL function pointer dereferenceBaruch reported an OOPS when using the designware controller as targetonly. Target-only modes break the assumption of one transfer functionalways 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-35984)In the Linux kernel, the following vulnerability has been resolved:ACPI: CPPC: Use access_width over bit_width for system memory accessesTo align with ACPI 6.3+, since bit_width can be any 8-bit value, itcannot be depended on to be always on a clean 8b boundary. This wasuncovered 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 tainted5.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/0x1a8Instead, use access_width to determine the size and use the offset andwidth to shift and mask the bits to read/write out. Make sure to add acheck for system memory since pcc redefines the access_width tosubspace id.If access_width is not set, then fall back to using bit_width.[ rjw: Subject and changelog edits, comment adjustments ](CVE-2024-35995)In the Linux kernel, the following vulnerability has been resolved:mm/hugetlb: fix missing hugetlb_lock for resv unchargeThere is a recent report on UFFDIO_COPY over hugetlb:https://lore.kernel.org/all/000000000000ee06de0616177560@google.com/350:&#x9;lockdep_assert_held(&amp;hugetlb_lock);Should be an issue in hugetlb but triggered in an userfault context, whereit goes into the unlikely path where two threads modifying the resv maptogether.  Mike has a fix in that path for resv uncharge but it looks likethe locking criteria was overlooked: hugetlb_cgroup_uncharge_folio_rsvd()will update the cgroup pointer, so it requires to be called with the lockheld.(CVE-2024-36000)In the Linux kernel, the following vulnerability has been resolved:ppdev: Add an error check in register_deviceIn 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. Whenthe index value is abnormal, a warning message should be printed, the portshould be dropped, and the value should be recorded.(CVE-2024-36015)In the Linux kernel, the following vulnerability has been resolved:pinctrl: core: delete incorrect free in pinctrl_enable()The &#34;pctldev&#34; struct is allocated in devm_pinctrl_register_and_init().It&#39;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 destroysthe mutex as well.(CVE-2024-36940)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-devel" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="5" arch="x86_64" name="perf-debuginfo" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.78.0.158.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.78.0.158.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1695</id>
          <title>An update for python-aiosmtpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34083" id="CVE-2024-34083" title="CVE-2024-34083" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-34083)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-aiosmtpd-help" release="1.oe2203sp1" version="1.4.6">
                         <filename>python-aiosmtpd-help-1.4.6-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-aiosmtpd" release="1.oe2203sp1" version="1.4.6">
                         <filename>python3-aiosmtpd-1.4.6-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1698</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-06-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4741" id="CVE-2024-4741" title="CVE-2024-4741" type="cve"></reference>
          </references>
          <description>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-4741)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="openssl-debuginfo" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-perl" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-libs" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-devel" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="openssl-debugsource" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-36.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="openssl-help" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-36.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-libs" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-devel" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debuginfo" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-perl" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="openssl-debugsource" release="36.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-36.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1699</id>
          <title>An update for grub2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-06-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-46848" id="CVE-2021-46848" title="CVE-2021-46848" type="cve"></reference>
          </references>
          <description>GNU Libtasn1 before 4.19.0 has an ETYPE_OK off-by-one array size check that affects asn1_encode_simple_der.(CVE-2021-46848)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="grub2-debugsource" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-debugsource-2.06-42.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-tools-2.06-42.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64-cdboot" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-cdboot-2.06-42.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-extra" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-tools-extra-2.06-42.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-efi-aa64" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-2.06-42.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-debuginfo" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-debuginfo-2.06-42.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="grub2-tools-minimal" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-tools-minimal-2.06-42.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-help" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-help-2.06-42.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-common" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-common-2.06-42.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-pc-modules" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-pc-modules-2.06-42.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-ia32-modules" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-modules-2.06-42.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-aa64-modules" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-aa64-modules-2.06-42.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="grub2-efi-x64-modules" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-modules-2.06-42.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-efi" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-tools-efi-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32-cdboot" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-cdboot-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debugsource" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-debugsource-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-pc" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-pc-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-debuginfo" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-debuginfo-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-ia32" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-ia32-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-tools-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-minimal" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-tools-minimal-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-tools-extra" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-tools-extra-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="grub2-efi-x64-cdboot" release="42.oe2203sp1" version="2.06">
                         <filename>grub2-efi-x64-cdboot-2.06-42.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1704</id>
          <title>An update for openjdk-11 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-06-07"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21011" id="CVE-2024-21011" title="CVE-2024-21011" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21012" id="CVE-2024-21012" title="CVE-2024-21012" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21068" id="CVE-2024-21068" title="CVE-2024-21068" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21085" id="CVE-2024-21085" title="CVE-2024-21085" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21094" id="CVE-2024-21094" title="CVE-2024-21094" type="cve"></reference>
          </references>
          <description>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-21011)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-21012)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-21068)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).(CVE-2024-21085)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-21094)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debugsource" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-debugsource-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-src-slowdebug-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-jmods-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-headless-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc-zip" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-javadoc-zip-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-devel-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-demo-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-src-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-slowdebug-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-javadoc-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debuginfo" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-debuginfo-11.0.23.9-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-demo-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debugsource" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-debugsource-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debuginfo" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-debuginfo-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-jmods-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-javadoc-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-src-slowdebug-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-src-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc-zip" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-javadoc-zip-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-devel-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-headless-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-slowdebug" release="2.oe2203sp1" version="11.0.23.9">
                         <filename>java-11-openjdk-slowdebug-11.0.23.9-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1706</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47247" id="CVE-2021-47247" title="CVE-2021-47247" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47265" id="CVE-2021-47265" title="CVE-2021-47265" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47356" id="CVE-2021-47356" title="CVE-2021-47356" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47558" id="CVE-2021-47558" title="CVE-2021-47558" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48652" id="CVE-2022-48652" title="CVE-2022-48652" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52646" id="CVE-2023-52646" title="CVE-2023-52646" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52677" id="CVE-2023-52677" title="CVE-2023-52677" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52680" id="CVE-2023-52680" title="CVE-2023-52680" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52686" id="CVE-2023-52686" title="CVE-2023-52686" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52702" id="CVE-2023-52702" title="CVE-2023-52702" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52705" id="CVE-2023-52705" title="CVE-2023-52705" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52745" id="CVE-2023-52745" title="CVE-2023-52745" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52746" id="CVE-2023-52746" title="CVE-2023-52746" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52753" id="CVE-2023-52753" title="CVE-2023-52753" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52775" id="CVE-2023-52775" title="CVE-2023-52775" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52796" id="CVE-2023-52796" title="CVE-2023-52796" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52798" id="CVE-2023-52798" title="CVE-2023-52798" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52799" id="CVE-2023-52799" title="CVE-2023-52799" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52800" id="CVE-2023-52800" title="CVE-2023-52800" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52803" id="CVE-2023-52803" title="CVE-2023-52803" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52807" id="CVE-2023-52807" title="CVE-2023-52807" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52865" id="CVE-2023-52865" title="CVE-2023-52865" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52875" id="CVE-2023-52875" title="CVE-2023-52875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27393" id="CVE-2024-27393" title="CVE-2024-27393" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27399" id="CVE-2024-27399" title="CVE-2024-27399" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27402" id="CVE-2024-27402" title="CVE-2024-27402" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27415" id="CVE-2024-27415" title="CVE-2024-27415" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35790" id="CVE-2024-35790" title="CVE-2024-35790" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35809" id="CVE-2024-35809" title="CVE-2024-35809" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35853" id="CVE-2024-35853" title="CVE-2024-35853" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35854" id="CVE-2024-35854" title="CVE-2024-35854" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35855" id="CVE-2024-35855" title="CVE-2024-35855" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35886" id="CVE-2024-35886" title="CVE-2024-35886" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35888" id="CVE-2024-35888" title="CVE-2024-35888" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35895" id="CVE-2024-35895" title="CVE-2024-35895" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35896" id="CVE-2024-35896" title="CVE-2024-35896" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35905" id="CVE-2024-35905" title="CVE-2024-35905" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35915" id="CVE-2024-35915" title="CVE-2024-35915" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35924" id="CVE-2024-35924" title="CVE-2024-35924" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35925" id="CVE-2024-35925" title="CVE-2024-35925" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35967" id="CVE-2024-35967" title="CVE-2024-35967" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35973" id="CVE-2024-35973" title="CVE-2024-35973" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36008" id="CVE-2024-36008" title="CVE-2024-36008" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36017" id="CVE-2024-36017" title="CVE-2024-36017" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36021" id="CVE-2024-36021" title="CVE-2024-36021" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36029" id="CVE-2024-36029" title="CVE-2024-36029" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36883" id="CVE-2024-36883" title="CVE-2024-36883" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36886" id="CVE-2024-36886" title="CVE-2024-36886" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36889" id="CVE-2024-36889" title="CVE-2024-36889" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36898" id="CVE-2024-36898" title="CVE-2024-36898" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36899" id="CVE-2024-36899" title="CVE-2024-36899" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36901" id="CVE-2024-36901" title="CVE-2024-36901" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36902" id="CVE-2024-36902" title="CVE-2024-36902" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36905" id="CVE-2024-36905" title="CVE-2024-36905" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36906" id="CVE-2024-36906" title="CVE-2024-36906" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36908" id="CVE-2024-36908" title="CVE-2024-36908" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36924" id="CVE-2024-36924" title="CVE-2024-36924" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36929" id="CVE-2024-36929" title="CVE-2024-36929" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36949" id="CVE-2024-36949" title="CVE-2024-36949" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36957" id="CVE-2024-36957" title="CVE-2024-36957" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36964" id="CVE-2024-36964" title="CVE-2024-36964" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Fix use-after-free of encap entry in neigh update handlerFunction mlx5e_rep_neigh_update() wasn&#39;t updated to accommodate rtnl lockremoval from TC filter update path and properly handle concurrent encapentry 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-2021-47247)In the Linux kernel, the following vulnerability has been resolved:RDMA: Verify port when creating flow ruleValidate port value provided by the user and with that remove no longerneeded validation by the driver.  The missing check in the mlx5_ib drivercould 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-2021-47265)In the Linux kernel, the following vulnerability has been resolved:mISDN: fix possible use-after-free in HFC_cleanup()This module&#39;s remove path calls del_timer(). However, that functiondoes not wait until the timer handler finishes. This means that thetimer handler may still be running after the driver&#39;s remove functionhas finished, which would result in a use-after-free.Fix by calling del_timer_sync(), which makes sure the timer handlerhas finished, and unable to re-schedule itself.(CVE-2021-47356)In the Linux kernel, the following vulnerability has been resolved:net: stmmac: Disable Tx queues when reconfiguring the interfaceThe Tx queues were not disabled in situations where the driver needed tostop the interface to apply a new configuration. This could result in akernel 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 stoppingan interface.Without this patch, the following kernel panic can be observed when doingany 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-2021-47558)In the Linux kernel, the following vulnerability has been resolved:ice: Fix crash by keep old cfg when update TCs more than queuesThere are problems if allocated queues less than Traffic Classes.Commit a632b2a4c920 (&#34;ice: ethtool: Prohibit improper channel configfor DCB&#34;) already disallow setting less queues than TCs.Another case is if we first set less queues, and later update more TCsconfig due to LLDP, ice_vsi_cfg_tc() will failed but left dirtynum_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/0xcaOnly update num_txq/rxq when passed check, and restore tc_cfg if setupqueue map failed.(CVE-2022-48652)In the Linux kernel, the following vulnerability has been resolved:aio: fix mremap after fork null-derefCommit e4a0d3e720e7 (&#34;aio: Make it possible to remap aio ring&#34;) introduceda null-deref if mremap is called on an old aio mapping after fork asmm-&gt;ioctx_table will be set to NULL.[jmoyer@redhat.com: fix 80 column issue](CVE-2023-52646)In the Linux kernel, the following vulnerability has been resolved:riscv: Check if the code to patch lies in the exit sectionOtherwise we fall through to vmalloc_to_page() which panics since theaddress does not lie in the vmalloc region.(CVE-2023-52677)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 notchecking the return value. Fix to check the return value and pass tothe caller.(CVE-2023-52680)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 memorywhich can be NULL upon failure.(CVE-2023-52686)In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix possible memory leak in ovs_meter_cmd_set()old_meter needs to be free after it is detached regardless of whetherthe new meter is successfully attached.(CVE-2023-52702)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix underflow in second superblock position calculationsMacro NILFS_SB2_OFFSET_BYTES, which computes the position of the secondsuperblock, underflows when the argument device size is less than 4096bytes.  Therefore, when using this macro, it is necessary to check inadvance that the device size is not less than a lower limit, or at leastthat underflow does not occur.The current nilfs2 implementation lacks this check, causing out-of-boundblock 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 4096bytes, this underflow occurs in nilfs_resize_fs(), passing a huge numberof segments to nilfs_sufile_resize(), corrupting parameters such as thenumber of segments in superblocks.  This causes excessive loop iterationsin nilfs_sufile_resize() during a subsequent resize ioctl, causingsemaphore ns_segctor_sem to block for a long time and hang the writerthread: INFO: task segctord:5067 blocked for more than 143 seconds.      Not tainted 6.2.0-rc8-syzkaller-00015-gf6feea56f66d #0 &#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; 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 sizechecks or anti-underflow checks, depending on where the macro is used.(CVE-2023-52705)In the Linux kernel, the following vulnerability has been resolved:IB/IPoIB: Fix legacy IPoIB due to wrong number of queuesThe cited commit creates child PKEY interfaces over netlink willmultiple tx and rx queues, but some devices doesn&#39;t support more than 1tx and 1 rx queues. This causes to a crash when traffic is sent over thePKEY interface due to the parent having a single queue but the childhaving multiple queues.This patch fixes the number of queues to 1 for legacy IPoIB at theearliest possible point in time.BUG: kernel NULL pointer dereference, address: 000000000000036bPGD 0 P4D 0Oops: 0000 [#1] SMPCPU: 4 PID: 209665 Comm: python3 Not tainted 6.1.0_for_upstream_min_debug_2022_12_12_17_02 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014RIP: 0010:kmem_cache_alloc+0xcb/0x450Code: 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 4a01 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 8bRSP: 0018:ffff88822acbbab8 EFLAGS: 00010202RAX: 0000000000000070 RBX: ffff8881c28e3e00 RCX: 00000000064f8daeRDX: 00000000064f8dad RSI: 0000000000000a20 RDI: 0000000000030d00RBP: 0000000000000a20 R08: ffff8882f5d30d00 R09: ffff888104032f40R10: ffff88810fade828 R11: 736f6d6570736575 R12: ffff88810081c000R13: 00000000000002fb R14: ffffffff817fc865 R15: 0000000000000000FS:  00007f9324ff9700(0000) GS:ffff8882f5d00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 000000000000036b CR3: 00000001125af004 CR4: 0000000000370ea0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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/0xb0RIP: 0033:0x7f9374f1ed14Code: 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 8b7c 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 8bRSP: 002b:00007f9324ff7bd0 EFLAGS: 00000293 ORIG_RAX: 000000000000002cRAX: ffffffffffffffda RBX: 00007f9324ff7cc8 RCX: 00007f9374f1ed14RDX: 00000000000002fb RSI: 00007f93000052f0 RDI: 0000000000000030RBP: 0000000000000000 R08: 00007f9324ff7d40 R09: 000000000000001cR10: 0000000000000000 R11: 0000000000000293 R12: 0000000000000000R13: 000000012a05f200 R14: 0000000000000001 R15: 00007f9374d57bdc &lt;/TASK&gt;(CVE-2023-52745)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 usedas a Spectre v1 gadget.  if (nla_len(nla) &lt; compat_policy[type].len) {array_index_nospec() can be used to prevent leakingcontent of kernel memory to malicious users.(CVE-2023-52746)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 beforeaccessing its funcs to prevent NULL dereference.(CVE-2023-52753)In the Linux kernel, the following vulnerability has been resolved:net/smc: avoid data corruption caused by declineWe found a data corruption issue during testing of SMC-R on Redisapplications.The benchmark has a low probability of reporting a strange error asshown below.&#34;Error: Protocol error, got &#34;\xe2&#34; as reply type byte&#34;Finally, we found that the retrieved error data was as follows:0xE2 0xD4 0xC3 0xD9 0x04 0x00 0x2C 0x20 0xA6 0x56 0x00 0x16 0x3E 0x0C0xCB 0x04 0x02 0x01 0x00 0x00 0x20 0x00 0x00 0x00 0x00 0x00 0x00 0x000x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0xE2It is quite obvious that this is a SMC DECLINE message, which means thatthe 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&#x9;&#x9;&#x9;send llc confirm        ¦failed llc confirm        ¦   x------(after 2s)timeout                        wait llc confirm rspwait decline(after 1s) timeout                        (after 2s) timeout        ¦   decline        --------------&gt;        ¦   decline        &lt;--------------As a result, a decline message was sent in the implementation, and thismessage 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 orcollide (during Confirm link timeout).This issue requires an immediate solution, since the protocol updatesinvolve a more long-term solution.(CVE-2023-52775)In the Linux kernel, the following vulnerability has been resolved:ipvlan: add ipvlan_route_v6_outbound() helperInspired by syzbot reports using a stack of multiple ipvlan devices.Reduce stack size needed in ipvlan_process_v6_outbound() by movingthe flowi6 struct used for the route lookup in an non inlinedhelper. 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 usessetups 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 KASANCPU: 0 PID: 13442 Comm: syz-executor.4 Not tainted 6.1.52-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/09/2023RIP: 0010:kasan_check_range+0x4/0x2a0 mm/kasan/generic.c:188Code: 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 89RSP: 0018:ffffc9000e804000 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff817e5bf2RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffffff887c6568RBP: ffffc9000e804000 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: dffffc0000000001 R12: 1ffff92001d0080cR13: dffffc0000000000 R14: ffffffff87e6b100 R15: 0000000000000000FS: 00007fd0c55826c0(0000) GS:ffff8881f6800000(0000) knlGS:0000000000000000CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000e803ff8 CR3: 0000000170ef7000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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-52796)In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix dfs radar event lockingThe ath11k active pdevs are protected by RCU but the DFS radar eventhandling code calling ath11k_mac_get_ar_by_pdev_id() was not marked as aread-side critical section.Mark the code in question as an RCU read-side critical section to avoidany potential use-after-free issues.Compile tested only.(CVE-2023-52798)In the Linux kernel, the following vulnerability has been resolved:jfs: fix array-index-out-of-bounds in dbFindLeafCurrently while searching for dmtree_t for sufficient free blocks thereis an array out of bounds while getting element in tp-&gt;dm_stree. To addthe required check for out of bound we first need to determine the typeof dmtree. Thus added an extra parameter to dbFindLeaf so that the typeof tree can be determined and the required check can be applied.(CVE-2023-52799)In the Linux kernel, the following vulnerability has been resolved:wifi: ath11k: fix htt pktlog lockingThe ath11k active pdevs are protected by RCU but the htt pktlog handlingcode calling ath11k_mac_get_ar_by_pdev_id() was not marked as aread-side critical section.Mark the code in question as an RCU read-side critical section to avoidany potential use-after-free issues.Compile tested only.(CVE-2023-52800)In the Linux kernel, the following vulnerability has been resolved:SUNRPC: Fix RPC client cleaned up the freed pipefs dentriesRPC client pipefs dentries cleanup is in separated rpc_remove_pipedir()workqueue,which takes care about pipefs superblock locking.In some special scenarios, when kernel frees the pipefs sb of thecurrent client and immediately alloctes a new pipefs sb,rpc_remove_pipedir function would misjudge the existence of pipefssb which is not the one it used to hold. As a result,the rpc_remove_pipedir would clean the released freed pipefs dentries.To fix this issue, rpc_remove_pipedir should check whether thecurrent pipefs sb is consistent with the original pipefs sb.This error can be catched by KASAN:=========================================================[  250.497700] BUG: KASAN: slab-use-after-free in dget_parent+0x195/0x200[  250.498315] Read of size 4 at addr ffff88800a2ab804 by task kworker/0:18/106503[  250.500549] Workqueue: events rpc_free_client_work[  250.501001] Call Trace:[  250.502880]  kasan_report+0xb6/0xf0[  250.503209]  ? dget_parent+0x195/0x200[  250.503561]  dget_parent+0x195/0x200[  250.503897]  ? __pfx_rpc_clntdir_depopulate+0x10/0x10[  250.504384]  rpc_rmdir_depopulate+0x1b/0x90[  250.504781]  rpc_remove_client_dir+0xf5/0x150[  250.505195]  rpc_free_client_work+0xe4/0x230[  250.505598]  process_one_work+0x8ee/0x13b0...[   22.039056] Allocated by task 244:[   22.039390]  kasan_save_stack+0x22/0x50[   22.039758]  kasan_set_track+0x25/0x30[   22.040109]  __kasan_slab_alloc+0x59/0x70[   22.040487]  kmem_cache_alloc_lru+0xf0/0x240[   22.040889]  __d_alloc+0x31/0x8e0[   22.041207]  d_alloc+0x44/0x1f0[   22.041514]  __rpc_lookup_create_exclusive+0x11c/0x140[   22.041987]  rpc_mkdir_populate.constprop.0+0x5f/0x110[   22.042459]  rpc_create_client_dir+0x34/0x150[   22.042874]  rpc_setup_pipedir_sb+0x102/0x1c0[   22.043284]  rpc_client_register+0x136/0x4e0[   22.043689]  rpc_new_client+0x911/0x1020[   22.044057]  rpc_create_xprt+0xcb/0x370[   22.044417]  rpc_create+0x36b/0x6c0...[   22.049524] Freed by task 0:[   22.049803]  kasan_save_stack+0x22/0x50[   22.050165]  kasan_set_track+0x25/0x30[   22.050520]  kasan_save_free_info+0x2b/0x50[   22.050921]  __kasan_slab_free+0x10e/0x1a0[   22.051306]  kmem_cache_free+0xa5/0x390[   22.051667]  rcu_core+0x62c/0x1930[   22.051995]  __do_softirq+0x165/0x52a[   22.052347][   22.052503] Last potentially related work creation:[   22.052952]  kasan_save_stack+0x22/0x50[   22.053313]  __kasan_record_aux_stack+0x8e/0xa0[   22.053739]  __call_rcu_common.constprop.0+0x6b/0x8b0[   22.054209]  dentry_free+0xb2/0x140[   22.054540]  __dentry_kill+0x3be/0x540[   22.054900]  shrink_dentry_list+0x199/0x510[   22.055293]  shrink_dcache_parent+0x190/0x240[   22.055703]  do_one_tree+0x11/0x40[   22.056028]  shrink_dcache_for_umount+0x61/0x140[   22.056461]  generic_shutdown_super+0x70/0x590[   22.056879]  kill_anon_super+0x3a/0x60[   22.057234]  rpc_kill_sb+0x121/0x200(CVE-2023-52803)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 debugfsThe hns3 driver define an array of string to show the coalesceinfo, but if the kernel adds a new mode or a new state,out-of-bounds access may occur when coalesce info is read viadebugfs, this patch fix the problem.(CVE-2023-52807)In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: clk-mt6797: Add check for mtk_alloc_clk_dataAdd the check for the return value of mtk_alloc_clk_data() in order toavoid NULL pointer dereference.(CVE-2023-52865)In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: clk-mt2701: Add check for mtk_alloc_clk_dataAdd the check for the return value of mtk_alloc_clk_data() in order toavoid NULL pointer dereference.(CVE-2023-52875)In the Linux kernel, the following vulnerability has been resolved:xen-netfront: Add missing skb_mark_for_recycleNotice that skb_mark_for_recycle() is introduced later than fixes tag incommit 6a5bcd84e886 (&#34;page_pool: Allow drivers to hint on SKB recycling&#34;).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 (incommit 535b9c61bdef (&#34;net: page_pool: hide page_pool_release_page()&#34;)and remaining callers converted (in commit 6bfef2ec0172 (&#34;Merge branch&#39;net-page_pool-remove-page_pool_release_page&#39;&#34;)).This leak became visible in v6.8 via commit dba1b8a7ab68 (&#34;mm/page_pool: catchpage_pool memory leaks&#34;).(CVE-2024-27393)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: l2cap: fix null-ptr-deref in l2cap_chan_timeoutThere is a race condition between l2cap_chan_timeout() andl2cap_chan_del(). When we use l2cap_chan_del() to delete thechannel, the chan-&gt;conn will be set to null. But the conn couldbe dereferenced again in the mutex_lock() of l2cap_chan_timeout().As a result the null pointer dereference bug will happen. TheKASAN 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-27399)In the Linux kernel, the following vulnerability has been resolved:phonet/pep: fix racy skb_queue_empty() useThe receive queues are protected by their respective spin-lock, notthe socket lock. This could lead to skb_peek() unexpectedlyreturning NULL or a pointer to an already dequeued socket buffer.(CVE-2024-27402)In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: confirm multicast packets before passing them up the stackconntrack nf_confirm logic cannot handle cloned skbs referencingthe 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 thatcase later steps perform skb_clone() with skb-&gt;_nfct already confirmed (inhash table).  This works fine.But such confirmation won&#39;t happen when eb/ip/nftables rules dropped thepackets before they reached the nf_confirm step in postrouting.Pablo points out that nf_conntrack_bridge doesn&#39;t allow use of statefulnat, so we can safely discard the nf_conn entry and let inet callconntrack again.This doesn&#39;t work for bridge netfilter: skb could have a nattransformation. Also bridge nf prevents re-invocation of inet preroutingvia &#39;sabotage_in&#39; hook.Work around this problem by explicit confirmation of the entry at LOCAL_INtime, 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 withunconfirmed packets, but even if that could be done in a sane way thisopens 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.5For multicast case, only one of such conflicting mappings will becreated, conntrack only handles 1:1 NAT mappings.Users should set create a setup that explicitly marks such trafficNOTRACK (conntrack bypass) to avoid this, but we cannot auto-bypassthem, ruleset might have accept rules for untracked traffic already,so user-visible behaviour would change.(CVE-2024-27415)In the Linux kernel, the following vulnerability has been resolved:usb: typec: altmodes/displayport: create sysfs nodes as driver&#39;s default device attribute groupThe DisplayPort driver&#39;s sysfs nodes may be present to the userspace beforetypec_altmode_set_drvdata() completes in dp_altmode_probe. This means thata sysfs read can trigger a NULL pointer error by deferencing dp-&gt;hpd inhpd_show or dp-&gt;lock in pin_assignment_show, as dev_get_drvdata() returnsNULL in those cases.Remove manual sysfs node creation in favor of adding attribute group asdefault for devices bound to the driver. The ATTRIBUTE_GROUPS() macro isnot used here otherwise the path to the sysfs nodes is no longer compliantwith the ABI.(CVE-2024-35790)In the Linux kernel, the following vulnerability has been resolved:PCI/PM: Drain runtime-idle callbacks before driver removalA race condition between the .runtime_idle() callback and the .remove()callback in the rtsx_pcr PCI driver leads to a kernel crash due to anunhandled page fault [1].The problem is that rtsx_pci_runtime_idle() is not expected to be runningafter pm_runtime_get_sync() has been called, but the latter doesn&#39;t reallyguarantee that.  It only guarantees that the suspend and resume callbackswill not be running when it returns.However, if a .runtime_idle() callback is already running whenpm_runtime_get_sync() is called, the latter will notice that the runtime PMstatus of the device is RPM_ACTIVE and it will return right away withoutwaiting for the former to complete.  In fact, it cannot wait for.runtime_idle() to complete because it may be called from that callback (itarguably does not make much sense to do that, but it is not strictlyprohibited).Thus in general, whoever is providing a .runtime_idle() callback needsto protect it from running in parallel with whatever code runs afterpm_runtime_get_sync().  [Note that .runtime_idle() will not start afterpm_runtime_get_sync() has returned, but it may continue running then if ithas 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 theruntime PM usage counter is necessary to prevent runtime PM callbacks frombeing invoked) to wait for the .runtime_idle() callback to complete shouldit be running at that point.  A suitable place for doing that is inpci_device_remove() which calls pm_runtime_get_sync() before removing thedriver, so it may as well call pm_runtime_barrier() subsequently, whichwill prevent the race in question from occurring, not just in the rtsx_pcrdriver, but in any PCI drivers providing .runtime_idle() callbacks.(CVE-2024-35809)In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix memory leak during rehashThe rehash delayed work migrates filters from one region to another.This is done by iterating over all chunks (all the filters with the samepriority) in the region and in each chunk iterating over all thefilters.If the migration fails, the code tries to migrate the filters back tothe old region. However, the rollback itself can also fail in which caseanother migration will be erroneously performed. Besides the fact thatthis ping pong is not a very good idea, it also creates a problem.Each virtual chunk references two chunks: The currently used one(&#39;vchunk-&gt;chunk&#39;) and a backup (&#39;vchunk-&gt;chunk2&#39;). During migration thefirst holds the chunk we want to migrate filters to and the second holdsthe chunk we are migrating filters from.The code currently assumes - but does not verify - that the backup chunkdoes not exist (NULL) if the currently used chunk does not reference thetarget region. This assumption breaks when we are trying to rollback arollback, resulting in the backup chunk being overwritten and leaked[1].Fix by not rolling back a failed rollback and add a warning to avoidfuture cases.[1]WARNING: CPU: 5 PID: 1063 at lib/parman.c:291 parman_destroy+0x17/0x20Modules linked in:CPU: 5 PID: 1063 Comm: kworker/5:11 Tainted: G        W          6.9.0-rc2-custom-00784-gc6a05c468a0b #14Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 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-35853)In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix possible use-after-free during rehashThe rehash delayed work migrates filters from one region to anotheraccording to the number of available credits.The migrated from region is destroyed at the end of the work if thenumber of credits is non-negative as the assumption is that this isindicative of migration being complete. This assumption is incorrect asa non-negative number of credits can also be the result of a failedmigration.The destruction of a region that still has filters referencing it canresult 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/0x230Read of size 8 at addr ffff8881735319e8 by task kworker/0:31/3858CPU: 0 PID: 3858 Comm: kworker/0:31 Tainted: G        W          6.9.0-rc2-custom-00782-gf2275c2157d8 #5Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workCall 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/0x30Freed 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-35854)In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix possible use-after-free during activity updateThe rule activity update delayed work periodically traverses the list ofconfigured rules and queries their activity from the device.As part of this task it accesses the entry pointed by &#39;ventry-&gt;entry&#39;,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&#39;vregion-&gt;lock&#39; mutex.[1]BUG: KASAN: slab-use-after-free in mlxsw_sp_acl_tcam_flower_rule_activity_get+0x121/0x140Read of size 8 at addr ffff8881054ed808 by task kworker/0:18/181CPU: 0 PID: 181 Comm: kworker/0:18 Not tainted 6.9.0-rc2-custom-00781-gd5ab772d32f7 #2Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_rule_activity_update_workCall 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/0x30Freed 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-35855)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() duringnetlink socket destruction.  [1]From the log, syzkaller sent an AF_UNSPEC RTM_GETROUTE message, and thenthe response was generated.  The following recvmmsg() resumed the dumpfor IPv6, but the first call of inet6_dump_fib() failed at kzalloc() dueto 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 callof inet6_dump_fib() set it to nlk_sk(sk)-&gt;cb.args[3].  syzkaller stoppedreceiving 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 itis still not NULL.  fib6_dump_end() rewrites nlk_sk(sk)-&gt;cb.done() bynlk_sk(sk)-&gt;cb.args[3], but it has the same function, not NULL, callingitself recursively and hitting the stack guard page.To avoid the issue, let&#39;s set the destructor after kzalloc().[0]:FAULT_INJECTION: forcing a failure.name failslab, interval 1, probability 0, space 0, times 0CPU: 1 PID: 432110 Comm: syz-executor.3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Call 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 KASANCPU: 1 PID: 223719 Comm: kworker/1:3 Not tainted 6.8.0-12821-g537c2e91d354-dirty #11Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014Workqueue: events netlink_sock_destruct_workRIP: 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 ffRSP: 0018:ffffc9000d980000 EFLAGS: 00010293RAX: 0000000000000000 RBX: ffffffff84405990 RCX: ffffffff844059d3RDX: ffff8881028e0000 RSI: ffffffff84405ac2 RDI: ffff88810c02f358RBP: ffff88810c02f358 R08: 0000000000000007 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000224 R12: 0000000000000000R13: ffff888007c82c78 R14: ffff888007c82c68 R15: ffff888007c82c68FS:  0000000000000000(0000) GS:ffff88811b100000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: ffffc9000d97fff8 CR3: 0000000102309002 CR4: 0000000000770ef0PKRU: 55555554Call 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-35886)In the Linux kernel, the following vulnerability has been resolved:erspan: make sure erspan_base_hdr is present in skb-&gt;headsyzbot reported a problem in ip6erspan_rcv() [1]Issue is that ip6erspan_rcv() (and erspan_rcv()) no longer makesure 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/0x75Uninit 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/0x75CPU: 1 PID: 5045 Comm: syz-executor114 Not tainted 6.9.0-rc1-syzkaller-00021-g962490525cff #0(CVE-2024-35888)In the Linux kernel, the following vulnerability has been resolved:bpf, sockmap: Prevent lock inversion deadlock in map delete elemsyzkaller started using corpuses where a BPF tracing program deleteselements from a sockmap/sockhash map. Because BPF tracing programs can beinvoked from any interrupt context, locks taken during a map_delete_elemoperation must be hardirq-safe. Otherwise a deadlock due to lock inversionis 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 bedeleted from sockmap/sockhash only in task (normal) context with interruptsenabled, 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 anerror.Note that map updates are not affected by this issue. BPF verifier does notallow updating sockmap/sockhash from a BPF tracing program today.(CVE-2024-35895)In the Linux kernel, the following vulnerability has been resolved:netfilter: validate user input for expected lengthI got multiple syzbot reports showing old bugs exposedby BPF after commit 20f2505fb436 (&#34;bpf: Try to avoid kzallocin cgroup/{s,g}etsockopt&#34;)setsockopt() @optlen argument should be taken into accountbefore 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:1627Read of size 96 at addr ffff88802cd73da0 by task syz-executor.4/7238CPU: 1 PID: 7238 Comm: syz-executor.4 Not tainted 6.9.0-rc2-next-20240403-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call 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/0x7aRIP: 0033:0x7fd22067dde9Code: 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 48RSP: 002b:00007fd21f9ff0c8 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 00007fd2207abf80 RCX: 00007fd22067dde9RDX: 0000000000000040 RSI: 0000000000000000 RDI: 0000000000000003RBP: 00007fd2206ca47a R08: 0000000000000001 R09: 0000000000000000R10: 0000000020000880 R11: 0000000000000246 R12: 0000000000000000R13: 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/0x7aThe buggy address belongs to the object at ffff88802cd73da0 which belongs to the cache kmalloc-8 of size 8The 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:0x2cd73flags: 0xfff80000000000(node=0|zone=1|lastcpupid=0xfff)page_type: 0xffffefff(slab)raw: 00fff80000000000 ffff888015041280 dead000000000100 dead000000000122raw: ffff88802cd73020 000000008080007f 00000001ffffefff 00---truncated---(CVE-2024-35896)In the Linux kernel, the following vulnerability has been resolved:bpf: Protect against int overflow for stack access sizeThis patch re-introduces protection against the size of access to stackmemory being negative; the access size can appear negative as a resultof overflowing its signed int representation. This should not actuallyhappen, as there are other protections along the way, but we shouldprotect against it anyway. One code path was missing such protections(fixed in the previous patch in the series), causing out-of-bounds arrayaccesses in check_stack_range_initialized(). This patch causes theverification of a program with such a non-sensical access size to fail.This check used to exist in a more indirect way, but was inadvertendlyremoved in a833a17aeac7.(CVE-2024-35905)In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix uninit-value in nci_dev_up and nci_ntf_packetsyzbot reported the following uninit-value access issue [1][2]:nci_rx_work() parses and processes received packet. When the payloadlength is zero, each message type handler reads uninitialized payloadand KMSAN detects this issue. The receipt of a packet with a zero-sizepayload is considered unexpected, and therefore, such packets should besilently discarded.This patch resolved this issue by checking payload size before callingeach message type handler codes.(CVE-2024-35915)In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Limit read size on v1.2Between UCSI 1.2 and UCSI 2.0, the size of the MESSAGE_IN region wasincreased from 16 to 256. In order to avoid overflowing reads for oldersystems, add a mechanism to use the read UCSI version to truncate readsizes on UCSI v1.2.(CVE-2024-35924)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 mayhave zero value on overflow. It is necessary to adda check to avoid division by zero.Found by Linux Verification Center (linuxtesting.org) with Svace.(CVE-2024-35925)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: SCO: Fix not validating setsockopt user inputsyzbot reported sco_sock_setsockopt() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in sco_sock_setsockopt+0xc0b/0xf90net/bluetooth/sco.c:893Read of size 4 at addr ffff88805f7b15a3 by task syz-executor.5/12578(CVE-2024-35967)In the Linux kernel, the following vulnerability has been resolved:geneve: fix header validation in geneve[6]_xmit_skbsyzbot 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 usingskb-&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 skblinear 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 thismore 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/0x75Uninit 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/0x75CPU: 0 PID: 5033 Comm: syz-executor346 Not tainted 6.9.0-rc1-syzkaller-00005-g928a87efa423 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024(CVE-2024-35973)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 KASANKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 2 PID: 3257 Comm: syz-executor.3 Not tainted 5.10.0-syzkaller #0Hardware 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:425Code: 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 bfRSP: 0018:ffffc900015fee40 EFLAGS: 00010246RAX: 0000000000000000 RBX: ffff88800f7a4000 RCX: ffff88800f4f90c0RDX: 0000000000000000 RSI: 0000000004001eac RDI: ffff8880160c64c0RBP: ffffc900015ff060 R08: 0000000000000000 R09: ffff88800f7a4000R10: 0000000000000002 R11: ffff88800f4f90c0 R12: dffffc0000000000R13: 0000000000000000 R14: 0000000000000000 R15: ffff88800f7a4000FS:  00007f938acfe6c0(0000) GS:ffff888058c00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f938acddd58 CR3: 000000001248e000 CR4: 0000000000352ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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-36008)In the Linux kernel, the following vulnerability has been resolved:rtnetlink: Correct nested IFLA_VF_VLAN_LIST attribute validationEach attribute inside a nested IFLA_VF_VLAN_LIST is assumed to be astruct ifla_vf_vlan_info so the size of such attribute needs to be at leastof 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 validationis not enough and a too small attribute might be cast to astruct ifla_vf_vlan_info, this might result in an out of bandsread access when accessing the saved (casted) entry in ivvl.(CVE-2024-36017)In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when devlink reload during pf initializationThe 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 kernelcrash. This patch fixes this by taking devl_lock during initialization.(CVE-2024-36021)In the Linux kernel, the following vulnerability has been resolved:mmc: sdhci-msm: pervent access to suspended controllerGeneric sdhci code registers LED device and uses host-&gt;runtime_suspendedflag to protect access to it. The sdhci-msm driver doesn&#39;t set this flag,which causes a crash when LED is accessed while controller is runtimesuspended. Fix this by setting the flag correctly.(CVE-2024-36029)In the Linux kernel, the following vulnerability has been resolved:net: fix out-of-bounds access in ops_initnet_alloc_generic is called by net_alloc, which is called without anylocking. It reads max_gen_ptrs, which is changed under pernet_ops_rwsem. Itis read twice, first to allocate an array, then to set s.len, which islater used to limit the bounds of the array access.It is possible that the array is allocated and another thread isregistering a new pernet ops, increments max_gen_ptrs, which is then usedto 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. Ifmax_gen_ptrs is later incremented, it will be caught in net_assign_generic.(CVE-2024-36883)In the Linux kernel, the following vulnerability has been resolved:tipc: fix UAF in error pathSam Page (sam4k) working with Trend Micro Zero Day Initiative reporteda UAF in the tipc_buf_append() error path:BUG: KASAN: slab-use-after-free in kfree_skb_list_reason+0x47e/0x4c0linux/net/core/skbuff.c:1183Read of size 8 at addr ffff88804d2a7c80 by task poc/8034CPU: 1 PID: 8034 Comm: poc Not tainted 6.8.2 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.16.0-debian-1.16.0-5 04/01/2014Call 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-36886)In the Linux kernel, the following vulnerability has been resolved:mptcp: ensure snd_nxt is properly initialized on connectChristoph 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  &#x9;8e 1a e7 fe 0f b7 ab 3e 02 00 00 e9 d3 fd ff ff e8 7d 1a e7 fe  &#x9;&lt;0f&gt; 0b 4c 8b bb e0 05 00 00 e9 74 fc ff ff e8 6a 1a e7 fe 0f 0b e9  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_nxtis not yet initialized and any incoming ack will copy such valueinto snd_una. If the mptcp worker (dumbly) tries mptcp-levelre-injection after such ack, that would unconditionally trigger a sendbuffer cleanup using &#39;bad&#39; snd_una values.We could easily disable re-injection for fallback sockets, but suchdumb behavior already helped catching a few subtle issues and a verylow to zero impact in practice.Instead address the issue always initializing snd_nxt (and write_seq,for consistency) at connect time.(CVE-2024-36889)In the Linux kernel, the following vulnerability has been resolved:gpiolib: cdev: fix uninitialised kfifoIf a line is requested with debounce, and that results in debouncingin software, and the line is subsequently reconfigured to enable edgedetection then the allocation of the kfifo to contain edge events isoverlooked.  This results in events being written to and read from anuninitialised kfifo.  Read events are returned to userspace.Initialise the kfifo in the case where the software debounce isalready active.(CVE-2024-36898)In the Linux kernel, the following vulnerability has been resolved:gpiolib: cdev: Fix use after free in lineinfo_changed_notifyThe use-after-free issue occurs as follows: when the GPIO chip device fileis being closed by invoking gpio_chrdev_release(), watched_lines is freedby bitmap_free(), but the unregistration of lineinfo_changed_nb notifierchain failed due to waiting write rwsem. Additionally, one of the GPIOchip&#39;s lines is also in the release process and holds the notifier chain&#39;sread rwsem. Consequently, a race condition leads to the use-after-free ofwatched_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 freeThe side effect of the use-after-free issue is that a GPIO line event isbeing generated for userspace where it shouldn&#39;t. However, since the chrdevis being closed, userspace won&#39;t have the chance to read that event anyway.To fix the issue, call the bitmap_free() function after the unregistrationof lineinfo_changed_nb notifier chain.(CVE-2024-36899)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 stackdeal 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 PTIKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]CPU: 0 PID: 9775 Comm: syz-executor.4 Not tainted 6.9.0-rc5-syzkaller-00157-g6a30653b604a #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024 RIP: 0010:ip6_output+0x231/0x3f0 net/ipv6/ip6_output.c:237Code: 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 ffRSP: 0018:ffffc9000927f0d8 EFLAGS: 00010202RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000040000RDX: ffffc900131f9000 RSI: 0000000000004f47 RDI: 0000000000004f48RBP: 0000000000000000 R08: ffffffff8a1f0b9a R09: 1ffffffff1f51fadR10: dffffc0000000000 R11: fffffbfff1f51fae R12: ffff8880293ec8c0R13: ffff88805d7fc000 R14: 1ffff1100527d91a R15: dffffc0000000000FS:  00007f135c6856c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000080 CR3: 0000000064096000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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-36901)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 PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 0 PID: 31648 Comm: syz-executor.0 Not tainted 6.9.0-rc4-next-20240417-syzkaller #0Hardware 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:267Code: 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 4cRSP: 0018:ffffc9000fc1f2f0 EFLAGS: 00010246RAX: 0000000000000000 RBX: 0000000000000000 RCX: 1a772f98c8186700RDX: 0000000000000003 RSI: ffffffff8bcac4e0 RDI: ffffffff8c1f9760RBP: ffff8880673fb980 R08: ffffffff8fac15ef R09: 1ffffffff1f582bdR10: dffffc0000000000 R11: fffffbfff1f582be R12: dffffc0000000000R13: 0000000000000080 R14: ffff888076509000 R15: ffff88807a029a00FS:  00007f55e82ca6c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b31d23000 CR3: 0000000022b66000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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-36902)In the Linux kernel, the following vulnerability has been resolved:tcp: defer shutdown(SEND_SHUTDOWN) for TCP_SYN_RECV socketsTCP_SYN_RECV state is really special, it is only used bycross-syn connections, mostly used by fuzzers.In the following crash [1], syzbot managed to trigger a divideby 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_CLOSEconnect()         TCP_SYN_SENT         TCP_SYN_RECVshutdown() -&gt; tcp_shutdown(sk, SEND_SHUTDOWN)         TCP_FIN_WAIT1To fix this issue, change tcp_shutdown() to notperform a TCP_SYN_RECV -&gt; TCP_FIN_WAIT1 transition,which makes no sense anyway.When tcp_rcv_state_process() later changes socket statefrom TCP_SYN_RECV to TCP_ESTABLISH, then look atsk-&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 BHcontext, and must use GFP_ATOMIC allocations.[1]divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 1 PID: 5084 Comm: syz-executor358 Not tainted 6.9.0-rc6-syzkaller-00022-g98369dccd2f8 #0Hardware 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:767Code: 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 48RSP: 0018:ffffc900031ef3f0 EFLAGS: 00010246RAX: 0c677a10441f8f42 RBX: 000000004fb95e7e RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: 0000000027d4b11f R08: ffffffff89e535a4 R09: 1ffffffff25e6ab7R10: dffffc0000000000 R11: ffffffff8135e920 R12: ffff88802a9f8d30R13: dffffc0000000000 R14: ffff88802a9f8d00 R15: 1ffff1100553f2daFS:  00005555775c0380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f1155bf2304 CR3: 000000002b9f2000 CR4: 0000000000350ef0Call 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/0x7fRIP: 0033:0x7faeb6363db9Code: 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 48RSP: 002b:00007ffcc1997168 EFLAGS: 00000246 ORIG_RAX: 000000000000012bRAX: ffffffffffffffda RBX: 0000000000000000 RCX: 00007faeb6363db9RDX: 0000000000000001 RSI: 0000000020000bc0 RDI: 0000000000000005RBP: 0000000000000000 R08: 0000000000000000 R09: 000000000000001cR10: 0000000000000122 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000001 R15: 0000000000000001(CVE-2024-36905)In the Linux kernel, the following vulnerability has been resolved:ARM: 9381/1: kasan: clear stale stack poisonWe 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) &#39;global_zone_diff&#39;[   33.470729]  [112, 276) &#39;global_node_diff&#39;[   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 stackpoison 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 problemFunctions which the compiler has instrumented for KASAN place poison onthe 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 inC code.  Any instrumented functions on this critical path will leaveportions of the stack shadow poisoned.If CPUs lose context and return to the kernel via a cold path, werestore a prior context saved in __cpu_suspend_enter are forgotten, andwe never remove the poison they placed in the stack shadow area byfunctions calls between this and the actual exit of the kernel.Thus, (depending on stackframe layout) subsequent calls to instrumentedfunctions may hit this stale poison, resulting in (spurious) KASANsplats to the console.To avoid this, clear any stale poison from the idle thread for a CPUprior to bringing a CPU online.From cited commit [2]Extend to check for CONFIG_KASAN_STACK[1] commit 0d97e6d8024c (&#34;arm64: kasan: clear stale stack poison&#34;)[2] commit d56a9ef84bd0 (&#34;kasan, arm64: unpoison stack only with CONFIG_KASAN_STACK&#34;)(CVE-2024-36906)In the Linux kernel, the following vulnerability has been resolved:blk-iocost: do not WARN if iocg was already offlinedIn iocg_pay_debt(), warn is triggered if &#39;active_list&#39; is empty, whichis intended to confirm iocg is active when it has debt. However, warncan 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/0x7b0The warn in this situation is meaningless. Since this iocg is beingremoved, the state of the &#39;active_list&#39; is irrelevant, and &#39;waitq_timer&#39;is canceled after removing &#39;active_list&#39; in ioc_pd_free(), which ensuresiocg is freed after iocg_waitq_timer_fn() returns.Therefore, add the check if iocg was already offlined to avoid warnwhen removing a blkcg or disk.(CVE-2024-36908)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 thehbalock.  Thus, lpfc_worker_wake_up() should not be called while holding thehbalock to avoid potential deadlock.(CVE-2024-36924)In the Linux kernel, the following vulnerability has been resolved:net: core: reject skb_copy(_expand) for fraglist GSO skbsSKB_GSO_FRAGLIST skbs must not be linearized, otherwise they becomeinvalid. Return NULL if such an skb is passed to skb_copy orskb_copy_expand, in order to prevent a crash on a potential latercall to skb_gso_segment.(CVE-2024-36929)In the Linux kernel, the following vulnerability has been resolved:amd/amdkfd: sync all devices to wait all processes being evictedIf there are more than one device doing reset in parallel, the firstdevice will call kfd_suspend_all_processes() to evict all processeson all devices, this call takes time to finish. other device willstart reset and recover without waiting. if the process has not beenevicted before doing recover, it will be restored, then caused pagefault.(CVE-2024-36949)In the Linux kernel, the following vulnerability has been resolved:octeontx2-af: avoid off-by-one read from userspaceWe try to access count + 1 byte from userspace with memdup_user(buffer,count + 1). However, the userspace only provides buffer of count bytes andonly these count bytes are verified to be okay to access. To ensure thecopied buffer is NUL terminated, we use memdup_user_nul instead.(CVE-2024-36957)In the Linux kernel, the following vulnerability has been resolved:fs/9p: only translate RWX permissions for plain 9P2000Garbage in plain 9P2000&#39;s perm bits is allowed through, which causes itto be able to set (among others) the suid bit. This was presumably notthe intent since the unix extended bits are handled explicitly andconditionally on .u.(CVE-2024-36964)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-headers" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.79.0.159.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.79.0.159.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.79.0.159.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1708</id>
          <title>An update for rubygem-actionpack is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28103" id="CVE-2024-28103" title="CVE-2024-28103" type="cve"></reference>
          </references>
          <description>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-2024-28103)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack" release="5.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-actionpack-6.1.4.1-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack-doc" release="5.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-actionpack-doc-6.1.4.1-5.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1711</id>
          <title>An update for mariadb is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-22084" id="CVE-2023-22084" title="CVE-2023-22084" type="cve"></reference>
          </references>
          <description>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-22084)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="mariadb-errmsg" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-errmsg-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-server-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-common" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-common-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-rocksdb-engine" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-rocksdb-engine-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-devel" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-devel-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-utils" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-server-utils-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-config" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-config-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-oqgraph-engine" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-oqgraph-engine-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-gssapi-server" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-gssapi-server-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-pam" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-pam-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-test" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-test-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-server-galera" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-server-galera-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-backup" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-backup-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-embedded-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debugsource" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-debugsource-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-embedded-devel" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-embedded-devel-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mariadb-debuginfo" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-debuginfo-10.5.25-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-errmsg" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-errmsg-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-pam" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-pam-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-embedded-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-backup" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-backup-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-test" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-test-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-config" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-config-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-oqgraph-engine" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-oqgraph-engine-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-devel" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-devel-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-common" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-common-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-galera" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-server-galera-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server-utils" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-server-utils-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debugsource" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-debugsource-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-debuginfo" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-debuginfo-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-embedded-devel" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-embedded-devel-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-server" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-server-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mariadb-gssapi-server" release="1.oe2203sp1" version="10.5.25">
                         <filename>mariadb-gssapi-server-10.5.25-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1715</id>
          <title>An update for libarchive is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20696" id="CVE-2024-20696" title="CVE-2024-20696" type="cve"></reference>
          </references>
          <description>Windows Libarchive Remote Code Execution Vulnerability(CVE-2024-20696)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libarchive-debugsource" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-debugsource-3.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive-debuginfo" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-debuginfo-3.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bsdcat" release="7.oe2203sp1" version="3.5.2">
                         <filename>bsdcat-3.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive-devel" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-devel-3.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libarchive" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-3.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bsdcpio" release="7.oe2203sp1" version="3.5.2">
                         <filename>bsdcpio-3.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="bsdtar" release="7.oe2203sp1" version="3.5.2">
                         <filename>bsdtar-3.5.2-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libarchive-help" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-help-3.5.2-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-debugsource" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-debugsource-3.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-devel" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-devel-3.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-3.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdcat" release="7.oe2203sp1" version="3.5.2">
                         <filename>bsdcat-3.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdcpio" release="7.oe2203sp1" version="3.5.2">
                         <filename>bsdcpio-3.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="bsdtar" release="7.oe2203sp1" version="3.5.2">
                         <filename>bsdtar-3.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libarchive-debuginfo" release="7.oe2203sp1" version="3.5.2">
                         <filename>libarchive-debuginfo-3.5.2-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1716</id>
          <title>An update for libvpx is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5197" id="CVE-2024-5197" title="CVE-2024-5197" type="cve"></reference>
          </references>
          <description>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(CVE-2024-5197)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libvpx-debuginfo" release="12.oe2203sp1" version="1.7.0">
                         <filename>libvpx-debuginfo-1.7.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx-debugsource" release="12.oe2203sp1" version="1.7.0">
                         <filename>libvpx-debugsource-1.7.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx" release="12.oe2203sp1" version="1.7.0">
                         <filename>libvpx-1.7.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvpx-devel" release="12.oe2203sp1" version="1.7.0">
                         <filename>libvpx-devel-1.7.0-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-debugsource" release="12.oe2203sp1" version="1.7.0">
                         <filename>libvpx-debugsource-1.7.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-debuginfo" release="12.oe2203sp1" version="1.7.0">
                         <filename>libvpx-debuginfo-1.7.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx" release="12.oe2203sp1" version="1.7.0">
                         <filename>libvpx-1.7.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvpx-devel" release="12.oe2203sp1" version="1.7.0">
                         <filename>libvpx-devel-1.7.0-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1718</id>
          <title>An update for mozjs78 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34481" id="CVE-2022-34481" title="CVE-2022-34481" type="cve"></reference>
          </references>
          <description>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-34481)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mozjs91-debuginfo" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debuginfo-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-devel" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-devel-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-debugsource" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debugsource-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libmozjs-91-0" release="5.oe2203sp1" version="91.6.0">
                         <filename>libmozjs-91-0-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-debugsource" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debugsource-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-devel" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-devel-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libmozjs-91-0" release="5.oe2203sp1" version="91.6.0">
                         <filename>libmozjs-91-0-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-debuginfo" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debuginfo-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1719</id>
          <title>An update for python-PyMySQL is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36039" id="CVE-2024-36039" title="CVE-2024-36039" type="cve"></reference>
          </references>
          <description>PyMySQL through 1.1.0 allows SQL injection if used with untrusted JSON input because keys are not escaped by escape_dict.(CVE-2024-36039)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-PyMySQL" release="4.oe2203sp1" version="0.9.3">
                         <filename>python3-PyMySQL-0.9.3-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1722</id>
          <title>An update for mpv is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-30145" id="CVE-2021-30145" title="CVE-2021-30145" type="cve"></reference>
          </references>
          <description>A format string vulnerability in mpv through 0.33.0 allows user-assisted remote attackers to achieve code execution via a crafted m3u playlist file.(CVE-2021-30145)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mpv-debuginfo" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-debuginfo-0.32.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mpv-libs" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-libs-0.32.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mpv-libs-devel" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-libs-devel-0.32.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mpv-debugsource" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-debugsource-0.32.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mpv" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-0.32.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-0.32.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv-libs" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-libs-0.32.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv-debuginfo" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-debuginfo-0.32.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv-debugsource" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-debugsource-0.32.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mpv-libs-devel" release="3.oe2203sp1" version="0.32.0">
                         <filename>mpv-libs-devel-0.32.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1723</id>
          <title>An update for libndp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5564" id="CVE-2024-5564" title="CVE-2024-5564" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-5564)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libndp-help" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-help-1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libndp-devel" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-devel-1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libndp-debugsource" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-debugsource-1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libndp" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libndp-debuginfo" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-debuginfo-1.8-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libndp-devel" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-devel-1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libndp" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libndp-debugsource" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-debugsource-1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libndp-help" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-help-1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libndp-debuginfo" release="3.oe2203sp1" version="1.8">
                         <filename>libndp-debuginfo-1.8-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1724</id>
          <title>An update for three-eight-nine-ds-base is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2199" id="CVE-2024-2199" title="CVE-2024-2199" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3657" id="CVE-2024-3657" title="CVE-2024-3657" type="cve"></reference>
          </references>
          <description>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-2199)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(CVE-2024-3657)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="389-ds-base-legacy-tools" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-snmp" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debuginfo" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debugsource" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-help" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-devel" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-389-ds" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>cockpit-389-ds-1.4.3.36-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-lib389" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>python3-lib389-1.4.3.36-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debugsource" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debuginfo" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-devel" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-legacy-tools" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-help" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-snmp" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base" release="6.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1725</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4854" id="CVE-2024-4854" title="CVE-2024-4854" type="cve"></reference>
          </references>
          <description>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-4854)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="8.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1731</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45733" id="CVE-2023-45733" title="CVE-2023-45733" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45745" id="CVE-2023-45745" title="CVE-2023-45745" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46103" id="CVE-2023-46103" title="CVE-2023-46103" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-47855" id="CVE-2023-47855" title="CVE-2023-47855" type="cve"></reference>
          </references>
          <description>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-45733)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-45745)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-46103)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-47855)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="1.oe2203sp1" version="20240531">
                         <filename>microcode_ctl-20240531-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1734</id>
          <title>An update for php is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5458" id="CVE-2024-5458" title="CVE-2024-5458" type="cve"></reference>
          </references>
          <description>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-5458)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="php-soap" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-help" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gd" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-xml" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-enchant" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-help" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="4.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1735</id>
          <title>An update for nano is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5742" id="CVE-2024-5742" title="CVE-2024-5742" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-5742)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="nano" release="1.oe2203sp1" version="8.0">
                         <filename>nano-8.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nano-debuginfo" release="1.oe2203sp1" version="8.0">
                         <filename>nano-debuginfo-8.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nano-debugsource" release="1.oe2203sp1" version="8.0">
                         <filename>nano-debugsource-8.0-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="nano-help" release="1.oe2203sp1" version="8.0">
                         <filename>nano-help-8.0-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nano-debuginfo" release="1.oe2203sp1" version="8.0">
                         <filename>nano-debuginfo-8.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nano" release="1.oe2203sp1" version="8.0">
                         <filename>nano-8.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nano-debugsource" release="1.oe2203sp1" version="8.0">
                         <filename>nano-debugsource-8.0-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1737</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47366" id="CVE-2021-47366" title="CVE-2021-47366" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48673" id="CVE-2022-48673" title="CVE-2022-48673" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48693" id="CVE-2022-48693" title="CVE-2022-48693" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52670" id="CVE-2023-52670" title="CVE-2023-52670" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52672" id="CVE-2023-52672" title="CVE-2023-52672" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52693" id="CVE-2023-52693" title="CVE-2023-52693" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52708" id="CVE-2023-52708" title="CVE-2023-52708" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52732" id="CVE-2023-52732" title="CVE-2023-52732" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52739" id="CVE-2023-52739" title="CVE-2023-52739" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52747" id="CVE-2023-52747" title="CVE-2023-52747" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52762" id="CVE-2023-52762" title="CVE-2023-52762" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52810" id="CVE-2023-52810" title="CVE-2023-52810" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52821" id="CVE-2023-52821" title="CVE-2023-52821" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52841" id="CVE-2023-52841" title="CVE-2023-52841" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52846" id="CVE-2023-52846" title="CVE-2023-52846" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52882" id="CVE-2023-52882" title="CVE-2023-52882" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26936" id="CVE-2024-26936" title="CVE-2024-26936" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26947" id="CVE-2024-26947" title="CVE-2024-26947" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26954" id="CVE-2024-26954" title="CVE-2024-26954" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26960" id="CVE-2024-26960" title="CVE-2024-26960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27014" id="CVE-2024-27014" title="CVE-2024-27014" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27019" id="CVE-2024-27019" title="CVE-2024-27019" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27044" id="CVE-2024-27044" title="CVE-2024-27044" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35796" id="CVE-2024-35796" title="CVE-2024-35796" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35815" id="CVE-2024-35815" title="CVE-2024-35815" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35819" id="CVE-2024-35819" title="CVE-2024-35819" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35828" id="CVE-2024-35828" title="CVE-2024-35828" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35839" id="CVE-2024-35839" title="CVE-2024-35839" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35870" id="CVE-2024-35870" title="CVE-2024-35870" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35887" id="CVE-2024-35887" title="CVE-2024-35887" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35910" id="CVE-2024-35910" title="CVE-2024-35910" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35932" id="CVE-2024-35932" title="CVE-2024-35932" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35935" id="CVE-2024-35935" title="CVE-2024-35935" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35937" id="CVE-2024-35937" title="CVE-2024-35937" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35951" id="CVE-2024-35951" title="CVE-2024-35951" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35965" id="CVE-2024-35965" title="CVE-2024-35965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35966" id="CVE-2024-35966" title="CVE-2024-35966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35982" id="CVE-2024-35982" title="CVE-2024-35982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36016" id="CVE-2024-36016" title="CVE-2024-36016" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36916" id="CVE-2024-36916" title="CVE-2024-36916" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36917" id="CVE-2024-36917" title="CVE-2024-36917" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36919" id="CVE-2024-36919" title="CVE-2024-36919" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36928" id="CVE-2024-36928" title="CVE-2024-36928" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36952" id="CVE-2024-36952" title="CVE-2024-36952" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36954" id="CVE-2024-36954" title="CVE-2024-36954" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36960" id="CVE-2024-36960" title="CVE-2024-36960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36968" id="CVE-2024-36968" title="CVE-2024-36968" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36971" id="CVE-2024-36971" title="CVE-2024-36971" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS serverAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, andLinux&#39;s afs client switches between them when talking to a non-YFS serverif the read size, the file position or the sum of the two have the upper 32bits set of the 64-bit value.This is a problem, however, since the file position and length fields ofFS.FetchData are *signed* 32-bit values.Fix this by capturing the capability bits obtained from the fileserver whenit&#39;s sent an FS.GetCapabilities RPC, rather than just discarding them, andthen picking out the VICED_CAPABILITY_64BITFILES flag.  This can then beused to decide whether to use FS.FetchData or FS.FetchData64 - and alsoFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() toswitch on the parameter values.This capabilities flag could also be used to limit the maximum size of thefile, 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&#39;s also not a problem with Auristor servers as itsYFS.FetchData64 op uses unsigned 64-bit values.This can be tested by cloning a git repo through an OpenAFS client to anOpenAFS server and then doing &#34;git status&#34; on it from a Linux afsclient[1].  Provided the clone has a pack file that&#39;s in the 2G-4G range,the git status will show errors like:&#x9;error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index&#x9;error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match indexThis can be observed in the server&#39;s FileLog with something like thefollowing appearing:Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866...Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5Note the file position of 18446744071815340032.  This is the requested fileposition sign-extended.(CVE-2021-47366)In the Linux kernel, the following vulnerability has been resolved:net/smc: Fix possible access to freed memory in link clearAfter modifying the QP to the Error state, all RX WR would be completedwith WC in IB_WC_WR_FLUSH_ERR status. Current implementation does notwait 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-48673)In the Linux kernel, the following vulnerability has been resolved:soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugsIn brcmstb_pm_probe(), there are two kinds of leak bugs:(1) we need to add of_node_put() when for_each__matching_node() breaks(2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)In the Linux kernel, the following vulnerability has been resolved:rpmsg: virtio: Free driver_override when rpmsg_remove()Free driver_override when rpmsg_remove(), otherwisethe following memory leak will occur:unreferenced object 0xffff0000d55d7080 (size 128):  comm &#34;kworker/u8:2&#34;, 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-2023-52670)In the Linux kernel, the following vulnerability has been resolved:pipe: wakeup wr_wait after setting max_usageCommit c73be61cede5 (&#34;pipe: Add general notification queue support&#34;) aregression was introduced that would lock up resized pipes under certainconditions. See the reproducer in [1].The commit resizing the pipe ring size was moved to a differentfunction, doing that moved the wakeup for pipe-&gt;wr_wait before actuallyraising pipe-&gt;max_usage. If a pipe was full before the resize occured itwould result in the wakeup never actually triggering pipe_write.Set @max_usage and @nr_accounted before waking writers if this isn&#39;t awatch queue.[Christian Brauner &lt;brauner@kernel.org&gt;: rewrite to account for watch queues](CVE-2023-52672)In the Linux kernel, the following vulnerability has been resolved:ACPI: video: check for error while searching for backlight device parentIf acpi_get_parent() called in acpi_video_dev_register_backlight()fails, for example, because acpi_ut_acquire_mutex() fails insideacpi_get_parent), this can lead to incorrect (uninitialized)acpi_parent handle being passed to acpi_get_pci_dev() for detectingthe 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-2023-52693)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&#39;t need to call mmc_remove_host(),or it will cause null-ptr-deref, because of deleting a not addeddevice in mmc_remove_host().To fix this, goto label &#39;fail_glue_init&#39;, if mmc_add_host() fails,and change the label &#39;fail_add_host&#39; to &#39;fail_gpiod_request&#39;.(CVE-2023-52708)In the Linux kernel, the following vulnerability has been resolved:ceph: blocklist the kclient when receiving corrupted snap traceWhen received corrupted snap trace we don&#39;t know what exactly hashappened in MDS side. And we shouldn&#39;t continue IOs and metadatasaccess to MDS, which may corrupt or get incorrect contents.This patch will just block all the further IO/MDS requestsimmediately and then evict the kclient itself.The reason why we still need to evict the kclient just afterblocking all the further IOs is that the MDS could revoke the capsfaster.(CVE-2023-52732)In the Linux kernel, the following vulnerability has been resolved:Fix page corruption caused by racy check in __free_pagesWhen we upgraded our kernel, we started seeing some page corruption likethe 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 pointerand cause crashes.After bisecting the issue, we found the issue started from commite320d3012d25 (&#34;mm/page_alloc.c: fix freeing non-compound pages&#34;):&#x9;if (put_page_testzero(page))&#x9;&#x9;free_the_page(page, order);&#x9;else if (!PageHead(page))&#x9;&#x9;while (order-- &gt; 0)&#x9;&#x9;&#x9;free_the_page(page + (1 &lt;&lt; order), order);So the problem is the check PageHead is racy because at this point wealready dropped our reference to the page.  So even if we came in withcompound page, the page can already be freed and PageHead can returnfalse and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Restore allocated resources on failed copyoutFix a resource leak if an error occurs.(CVE-2023-52747)In the Linux kernel, the following vulnerability has been resolved:virtio-blk: fix implicit overflow on virtio_max_dma_sizeThe 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. Oncevirtio_max_dma_size() has a larger size than U32_MAX, use U32_MAXinstead.(CVE-2023-52762)In the Linux kernel, the following vulnerability has been resolved:fs/jfs: Add check for negative db_l2nbperpagel2nbperpage is log2(number of blks per page), and the minimum legalvalue should be 0, not negative.In the case of l2nbperpage being negative, an error will occurwhen subsequently used as shift exponent.Syzbot reported this bug:UBSAN: shift-out-of-bounds in fs/jfs/jfs_dmap.c:799:12shift exponent -16777216 is negative(CVE-2023-52810)In the Linux kernel, the following vulnerability has been resolved:drm/panel: fix a possible null pointer dereferenceIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)In the Linux kernel, the following vulnerability has been resolved:media: vidtv: mux: Add check and kfree for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.Moreover, use kfree() in the later error handling in order to avoidmemory leak.(CVE-2023-52841)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 theskb and returns NULL.  Meanwhile on the success path, it returns theoriginal skb.  So it&#39;s straight forward to fix bug by using the returnedvalue.(CVE-2023-52846)In the Linux kernel, the following vulnerability has been resolved:clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate changeWhile PLL CPUX clock rate change when CPU is running from it works invast majority of cases, now and then it causes instability. This leadsto system crashes and other undefined behaviour. After a lot of testing(30+ hours) while also doing a lot of frequency switches, we can&#39;tobserve any instability issues anymore when doing reparenting to stableclock like 24 MHz oscillator.(CVE-2023-52882)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_bufbefore validating request. But the fields in payload as well as smb2 headeris used in smb2_allocate_rsp_buf(). This patch add simple buffer sizevalidation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)In the Linux kernel, the following vulnerability has been resolved:ARM: 9359/1: flush: check if the folio is reserved for no-mapping addressesSince commit a4d5613c4dc6 (&#34;arm: extend pfn_valid to take into accountfreed memory map alignment&#34;) changes the semantics of pfn_valid() to checkpresence of the memory map for a PFN. A valid page for an address whichis reserved but not mapped by the kernel[1], the system crashed duringsome uio test with the following memory layout: node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node   0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000the 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 exceptionSo check if PG_reserved was set to solve this issue.[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/(CVE-2024-26947)In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()If -&gt;NameOffset of smb2_create_req is smaller than Buffer offset ofsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.This patch set the minimum value of the name offset to the buffer offsetto validate name length of smb2_create_req().(CVE-2024-26954)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 andteardown a swap_info_struct while a call to free_swap_and_cache() wasrunning in another thread.  This could cause, amongst other badpossibilities, swap_page_trans_huge_swapped() (called byfree_swap_and_cache()) to access the freed memory for swap_map.This is a theoretical problem and I haven&#39;t been able to provoke it from atest case.  But there has been agreement based on code review that this ispossible (see link below).Fix it by using get_swap_device()/put_swap_device(), which will stallswapoff().  There was an extra check in _swap_info_get() to confirm thatthe swap entry was not free.  This isn&#39;t present in get_swap_device()because it doesn&#39;t make sense in general due to the race between gettingthe reference and swapoff.  So I&#39;ve added an equivalent check directly infree_swap_and_cache().Details of how to provoke one possible issue (thanks to David Hildenbrandfor deriving this):--8&lt;-----__swap_entry_free() might be the last user and result in&#34;count == SWAP_HAS_CACHE&#34;.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 turnsi-&gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages arestill 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_CACHEProcess 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 cachebut before process1 finished its call to swap_page_trans_huge_swapped()?--8&lt;-----(CVE-2024-26960)In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv-&gt;state_lock`, any scheduledaRFS 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 willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker&#39;s responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.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/0x4e0but 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/0x4eother 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 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call 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-27014)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_objectslist in __nft_obj_type_get(). Therefore, there is potential data-raceof nf_tables_objects list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_objectslist in __nft_obj_type_get(), and use rcu_read_lock() in the callernft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential NULL pointer dereferences in &#39;dcn10_set_output_transfer_func()&#39;The &#39;stream&#39; pointer is used in dcn10_set_output_transfer_func() beforethe check if &#39;stream&#39; is NULL.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check &#39;stream&#39; (see line 1875)(CVE-2024-27044)In the Linux kernel, the following vulnerability has been resolved:net: ll_temac: platform_get_resource replaced by wrong functionThe function platform_get_resource was replaced withdevm_platform_ioremap_resource_byname and is called using 0 as name.This eventually ends up in platform_get_resource_byname in the callstack, where it causes a null pointer in strcmp.&#x9;if (type == resource_type(r) &amp;&amp; !strcmp(r-&gt;name, name))It should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)In the Linux kernel, the following vulnerability has been resolved:fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversionThe first kiocb_set_cancel_fn() argument may point at a struct kiocbthat is not embedded inside struct aio_kiocb. With the current code,depending on the compiler, the req-&gt;ki_ctx read happens either beforethe IOCB_AIO_RW test or after that test. Move the req-&gt;ki_ctx read suchthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)In the Linux kernel, the following vulnerability has been resolved:soc: fsl: qbman: Use raw spinlock for cgr_locksmp_call_function always runs its callback in hard IRQ context, even onPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlockfor cgr_lock to ensure we aren&#39;t waiting on a sleeping task.Although this bug has existed for a while, it was not apparent untilcommit ef2a8d5478b9 (&#34;net: dpaa: Adjust queue depth on rate change&#34;)which invokes smp_call_function_single via qman_update_cgr_safe everytime a link goes up or down.(CVE-2024-35819)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 ofcmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs tobe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh-&gt;arp_queue while waiting for an arpreply. Where original skb&#39;s skb-&gt;dev can be different to neigh&#39;sneigh-&gt;dev. For instance in case of bridging dnated skb from one veth toanother, 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 asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn&#39;t cleanup skbs fromdifferent device&#39;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_finishLet&#39;s use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don&#39;t get it and drop skb.(CVE-2024-35839)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 thatis already being teared down by another thread that is executing__cifs_put_smb_ses().  This can happen when (a) the client hasconnection to the server but no session or (b) another thread ends upsetting @ses-&gt;ses_status again to something different thanSES_EXITING.To fix this, we need to make sure to unconditionally set@ses-&gt;ses_status to SES_EXITING and prevent any other threads fromsetting a new status while we&#39;re still tearing it down.The following can be reproduced by adding some delay to right afterthe ipc is freed in __cifs_put_smb_ses() - which will givesmb2_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/nullsleep 30kdestroy[reconnect srv]sleep 10umount /mnt/1...CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126general protection fault, probably for non-canonical address0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc3904/01/2014Workqueue: cifsiod smb2_reconnect_server [cifs]RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 adde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 &lt;48&gt; 8b 01 48 39 f8 757b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6bRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000FS: 0000000000000000(0000) GS:ffff888157c00000(0000)knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0PKRU: 55555554Call 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-35870)In the Linux kernel, the following vulnerability has been resolved:ax25: fix use-after-free bugs caused by ax25_ds_del_timerWhen the ax25 device is detaching, the ax25_dev_device_down()calls ax25_ds_del_timer() to cleanup the slave_timer. Whenthe timer handler is running, the ax25_ds_del_timer() thatcalls del_timer() in it will return directly. As a result,the use-after-free bugs could happen, one of the scenariosis 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; //USEIn order to mitigate bugs, when the device is detaching, usetimer_shutdown_sync() to stop the timer.(CVE-2024-35887)In the Linux kernel, the following vulnerability has been resolved:tcp: properly terminate timers for kernel socketsWe had various syzbot reports about tcp timers firing afterthe 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 &#39;stop&#39; 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 timerholds a reference on the socket, and the user socket holdsa reference on the netns.For kernel sockets, we risk that the netns is freed beforetimer can complete, because kernel sockets do not holdreference on the netns.This patch adds inet_csk_clear_xmit_timers_sync() functionthat using sk_stop_timer_sync() to make sure all timersare 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 LOCKDEPsupport : inet_csk_clear_xmit_timers_sync() must not be calledwhile socket lock is held.It is very possible we can revert in the future commit3a58f13a881e (&#34;net: rds: acquire refcount on TCP sockets&#34;)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 fromtcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)In the Linux kernel, the following vulnerability has been resolved:drm/vc4: don&#39;t check if plane-&gt;state-&gt;fb == state-&gt;fbCurrently, when using non-blocking commits, we can see the followingkernel 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` areperfectly balanced, we cannot guarantee consistency in the checkplane-&gt;state-&gt;fb == state-&gt;fb. This means that sometimes we can increasethe refcount in `prepare_fb` and don&#39;t decrease it in `cleanup_fb`. Theopposite can also be true.In fact, the struct drm_plane .state shouldn&#39;t be accessed directlybut instead, the `drm_atomic_get_new_plane_state()` helper function shouldbe 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-35932)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 bufferfails. The pointers are not printed so we don&#39;t accidentally leak kerneladdresses.(CVE-2024-35935)In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: check A-MSDU format more carefullyIf it looks like there&#39;s another subframe in the A-MSDUbut the header isn&#39;t fully there, we can end up readingdata out of bounds, only to discard later. Make this abit more careful and check if the subframe header caneven be present.(CVE-2024-35937)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&#39;t release thepages ref we got earlier, otherwise we will end up with unbalancedget/put_pages() calls. We should instead leave everything in placeand let the BO release function deal with extra cleanup when the objectis destroyed, or let the fault handler try again next time it&#39;s called.(CVE-2024-35951)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix not validating setsockopt user inputCheck user input length before copying data.(CVE-2024-35965)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: Fix not validating setsockopt user inputsyzbot reported rfcomm_sock_setsockopt_old() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_oldnet/bluetooth/rfcomm/sock.c:632 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70net/bluetooth/rfcomm/sock.c:673Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)In the Linux kernel, the following vulnerability has been resolved:batman-adv: Avoid infinite loop trying to resize local TTIf the MTU of one of an attached interface becomes too small to transmitthe local translation table then it must be resized to fit inside allfragments (when enabled) or a single packet.But if the MTU becomes too low to transmit even the header + the VLANspecific part then the resizing of the local TT will never succeed. Thiscan for example happen when the usable space is 110 bytes and 11 VLANs areon 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 thetimeout will be halved all the time and will then stagnate at 0 andtherefore never be able to reduce the table even more.There are other scenarios possible with a similar result. The number ofBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be toohigh to fit inside a packet. Such a scenario can therefore happen also withonly a single VLAN + 7 non-purgable addresses - requiring at least 120bytes.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 onlyconsuming 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 handlealso the situations when there were already incompatible systemconfiguration are present.(CVE-2024-35982)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 lessthan. Also add upper limit checks against the constant MAX_MRU ingsm0_receive() and gsm1_receive() to harden against memory corruption ofgsm-&gt;len and gsm-&gt;mru.All other checks remain as we still need to limit the data according to theuser configuration and actual payload size.(CVE-2024-36016)In the Linux kernel, the following vulnerability has been resolved:blk-iocost: avoid out of bounds shiftUBSAN catches undefined behavior in blk-iocost, where sometimesiocg-&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:23shift exponent 64 is too large for 64-bit type &#39;u64&#39; (aka &#39;unsigned long long&#39;)CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020Call 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&#34;delay = 0&#34; branch if the shift is too large.I am not sure what the symptoms of an undefined valuedelay will be, but I suspect it could be more than alittle annoying to debug.(CVE-2024-36916)In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of &#39;start + len&#39; in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param:  start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.(CVE-2024-36917)In the Linux kernel, the following vulnerability has been resolved:scsi: bnx2fc: Remove spin_lock_bh while releasing resources after uploadThe session resources are used by FW and driver when session is offloaded,once session is uploaded these resources are not used. The lock is notrequired as these fields won&#39;t be used any longer. The offload and uploadcalls 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 #1Rebooting.[  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-36919)In the Linux kernel, the following vulnerability has been resolved:s390/qeth: Fix kernel panic after setting hsuidSymptom:When the hsuid attribute is set for the first time on an IQD Layer3device 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_ipv6nft_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 des_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].napiThe napi.poll functions are set during qeth_open().Sincecommit 1cfef80d4c2b (&#34;s390/qeth: Don&#39;t call dev_close/dev_open (DOWN/UP)&#34;)qeth_set_offline()/qeth_set_online() no longer call dev_close()/dev_open(). So if qeth_free_qdio_queues() clearedcard-&gt;qdio.out_qs[i].napi.poll while the network interface was UP and thecard was offline, they are not set again.Reproduction:chzdev -e $devno layer2=0ip link set dev $network_interface upecho 0 &gt; /sys/bus/ccw---truncated---(CVE-2024-36928)In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Move NPIV&#39;s transport unregistration to after resource clean upThere are cases after NPIV deletion where the fabric switch still believesthe NPIV is logged into the fabric.  This occurs when a vport isunregistered before the Remove All DA_ID CT and LOGO ELS are sent to thefabric.Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs includingthe fabric D_ID, removes the last ndlp reference and frees the ndlp rportobject.  This sometimes causes the race condition where the final DA_ID andLOGO are skipped from being sent to the fabric switch.Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_IDand LOGO are sent.(CVE-2024-36952)In the Linux kernel, the following vulnerability has been resolved:tipc: fix a possible memleak in tipc_buf_append__skb_linearize() doesn&#39;t free the skb when it fails, so move&#39;*buf = NULL&#39; after __skb_linearize(), so that the skb can befreed on the err path.(CVE-2024-36954)In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix invalid reads in fence signaled eventsCorrectly set the length of the drm_event to the size of the structurethat&#39;s actually used.The length of the drm_event was set to the parent structure instead ofto the drm_vmw_event_fence which is supposed to be read. drm_readuses the length parameter to copy the event to the user space thusresuling in oob reads.(CVE-2024-36960)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 integeroverflow 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 connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 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 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call 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-2024-36968)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-36971)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-source" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1739</id>
          <title>An update for ntfs-3g is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52890" id="CVE-2023-52890" title="CVE-2023-52890" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-52890)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="ntfs-3g-help" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-help-2022.5.17-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ntfs-3g-devel" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-devel-2022.5.17-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ntfs-3g-debugsource" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-debugsource-2022.5.17-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ntfs-3g" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-2022.5.17-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="ntfs-3g-debuginfo" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-debuginfo-2022.5.17-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ntfs-3g-debugsource" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-debugsource-2022.5.17-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ntfs-3g-debuginfo" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-debuginfo-2022.5.17-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ntfs-3g" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-2022.5.17-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ntfs-3g-devel" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-devel-2022.5.17-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="ntfs-3g-help" release="3.oe2203sp1" version="2022.5.17">
                         <filename>ntfs-3g-help-2022.5.17-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1740</id>
          <title>An update for busybox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42363" id="CVE-2023-42363" title="CVE-2023-42363" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42364" id="CVE-2023-42364" title="CVE-2023-42364" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42365" id="CVE-2023-42365" title="CVE-2023-42365" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42366" id="CVE-2023-42366" title="CVE-2023-42366" type="cve"></reference>
          </references>
          <description>A use-after-free vulnerability was discovered in xasprintf function in xfuncs_printf.c:344 in BusyBox v.1.36.1.(CVE-2023-42363)A use-after-free vulnerability in BusyBox v.1.36.1 allows attackers to cause a denial of service via a crafted awk pattern in the awk.c evaluate function.(CVE-2023-42364)A use-after-free vulnerability was discovered in BusyBox v.1.36.1 via a crafted awk pattern in the awk.c copyvar function.(CVE-2023-42365)A heap-buffer-overflow was discovered in BusyBox v.1.36.1 in the next_token function at awk.c:1159.(CVE-2023-42366)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="busybox-help" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-help-1.34.1-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-1.34.1-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-debuginfo" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-debuginfo-1.34.1-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-debugsource" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-debugsource-1.34.1-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="busybox-petitboot" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-petitboot-1.34.1-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-1.34.1-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-debugsource" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-debugsource-1.34.1-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-debuginfo" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-debuginfo-1.34.1-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-petitboot" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-petitboot-1.34.1-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="busybox-help" release="20.oe2203sp1" version="1.34.1">
                         <filename>busybox-help-1.34.1-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1741</id>
          <title>An update for expat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52425" id="CVE-2023-52425" title="CVE-2023-52425" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-52425)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="expat" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-2.4.1-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debugsource" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debuginfo" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-devel" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-devel-2.4.1-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="expat-help" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-help-2.4.1-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-2.4.1-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-devel" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-devel-2.4.1-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debuginfo" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debugsource" release="11.oe2203sp1" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1745</id>
          <title>An update for python-scikit-learn is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5206" id="CVE-2024-5206" title="CVE-2024-5206" type="cve"></reference>
          </references>
          <description>A sensitive data leakage vulnerability was identified in scikit-learn&#39;s TfidfVectorizer, specifically in versions up to and including 1.4.1.post1, which was fixed in version 1.5.0. The vulnerability arises from the unexpected storage of all tokens present in the training data within the `stop_words_` attribute, rather than only storing the subset of tokens required for the TF-IDF technique to function. This behavior leads to the potential leakage of sensitive information, as the `stop_words_` attribute could contain tokens that were meant to be discarded and not stored, such as passwords or keys. The impact of this vulnerability varies based on the nature of the data being processed by the vectorizer.(CVE-2024-5206)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-scikit-learn" release="2.oe2203sp1" version="1.1.1">
                         <filename>python3-scikit-learn-1.1.1-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-scikit-learn" release="2.oe2203sp1" version="1.1.1">
                         <filename>python3-scikit-learn-1.1.1-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1747</id>
          <title>An update for mozjs78 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-29532" id="CVE-2023-29532" title="CVE-2023-29532" type="cve"></reference>
          </references>
          <description>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-29532)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mozjs91" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-debugsource" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debugsource-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libmozjs-91-0" release="5.oe2203sp1" version="91.6.0">
                         <filename>libmozjs-91-0-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-debuginfo" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debuginfo-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-devel" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-devel-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libmozjs-91-0" release="5.oe2203sp1" version="91.6.0">
                         <filename>libmozjs-91-0-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-debuginfo" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debuginfo-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-devel" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-devel-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-debugsource" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debugsource-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1751</id>
          <title>An update for python-lxml is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37388" id="CVE-2024-37388" title="CVE-2024-37388" type="cve"></reference>
          </references>
          <description>An XML External Entity (XXE) vulnerability in the ebookmeta.get_metadata function of lxml before v4.9.1 allows attackers to access sensitive information or cause a Denial of Service (DoS) via crafted XML input.(CVE-2024-37388)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-lxml" release="6.oe2203sp1" version="4.7.1">
                         <filename>python3-lxml-4.7.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-lxml-debuginfo" release="6.oe2203sp1" version="4.7.1">
                         <filename>python-lxml-debuginfo-4.7.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python-lxml-debugsource" release="6.oe2203sp1" version="4.7.1">
                         <filename>python-lxml-debugsource-4.7.1-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-lxml-help" release="6.oe2203sp1" version="4.7.1">
                         <filename>python-lxml-help-4.7.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-lxml-debuginfo" release="6.oe2203sp1" version="4.7.1">
                         <filename>python-lxml-debuginfo-4.7.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python-lxml-debugsource" release="6.oe2203sp1" version="4.7.1">
                         <filename>python-lxml-debugsource-4.7.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-lxml" release="6.oe2203sp1" version="4.7.1">
                         <filename>python3-lxml-4.7.1-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1752</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1298" id="CVE-2024-1298" title="CVE-2024-1298" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-1298)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="18.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="18.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="18.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="18.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="18.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="18.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="18.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-18.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="18.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="18.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="18.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1753</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-21"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47366&amp;packageName=kernel" id="CVE-2021-47366&amp;packageName=kernel" title="CVE-2021-47366&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48673&amp;packageName=kernel" id="CVE-2022-48673&amp;packageName=kernel" title="CVE-2022-48673&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48693&amp;packageName=kernel" id="CVE-2022-48693&amp;packageName=kernel" title="CVE-2022-48693&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52670&amp;packageName=kernel" id="CVE-2023-52670&amp;packageName=kernel" title="CVE-2023-52670&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52672&amp;packageName=kernel" id="CVE-2023-52672&amp;packageName=kernel" title="CVE-2023-52672&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52693&amp;packageName=kernel" id="CVE-2023-52693&amp;packageName=kernel" title="CVE-2023-52693&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52708&amp;packageName=kernel" id="CVE-2023-52708&amp;packageName=kernel" title="CVE-2023-52708&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52732&amp;packageName=kernel" id="CVE-2023-52732&amp;packageName=kernel" title="CVE-2023-52732&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52739&amp;packageName=kernel" id="CVE-2023-52739&amp;packageName=kernel" title="CVE-2023-52739&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52747&amp;packageName=kernel" id="CVE-2023-52747&amp;packageName=kernel" title="CVE-2023-52747&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52762&amp;packageName=kernel" id="CVE-2023-52762&amp;packageName=kernel" title="CVE-2023-52762&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52821&amp;packageName=kernel" id="CVE-2023-52821&amp;packageName=kernel" title="CVE-2023-52821&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52841&amp;packageName=kernel" id="CVE-2023-52841&amp;packageName=kernel" title="CVE-2023-52841&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52846&amp;packageName=kernel" id="CVE-2023-52846&amp;packageName=kernel" title="CVE-2023-52846&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52882&amp;packageName=kernel" id="CVE-2023-52882&amp;packageName=kernel" title="CVE-2023-52882&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26936&amp;packageName=kernel" id="CVE-2024-26936&amp;packageName=kernel" title="CVE-2024-26936&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26947&amp;packageName=kernel" id="CVE-2024-26947&amp;packageName=kernel" title="CVE-2024-26947&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26954&amp;packageName=kernel" id="CVE-2024-26954&amp;packageName=kernel" title="CVE-2024-26954&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26960&amp;packageName=kernel" id="CVE-2024-26960&amp;packageName=kernel" title="CVE-2024-26960&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27014&amp;packageName=kernel" id="CVE-2024-27014&amp;packageName=kernel" title="CVE-2024-27014&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27019&amp;packageName=kernel" id="CVE-2024-27019&amp;packageName=kernel" title="CVE-2024-27019&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27044&amp;packageName=kernel" id="CVE-2024-27044&amp;packageName=kernel" title="CVE-2024-27044&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35796&amp;packageName=kernel" id="CVE-2024-35796&amp;packageName=kernel" title="CVE-2024-35796&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35815&amp;packageName=kernel" id="CVE-2024-35815&amp;packageName=kernel" title="CVE-2024-35815&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35819&amp;packageName=kernel" id="CVE-2024-35819&amp;packageName=kernel" title="CVE-2024-35819&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35828&amp;packageName=kernel" id="CVE-2024-35828&amp;packageName=kernel" title="CVE-2024-35828&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35839&amp;packageName=kernel" id="CVE-2024-35839&amp;packageName=kernel" title="CVE-2024-35839&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35870&amp;packageName=kernel" id="CVE-2024-35870&amp;packageName=kernel" title="CVE-2024-35870&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35887&amp;packageName=kernel" id="CVE-2024-35887&amp;packageName=kernel" title="CVE-2024-35887&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35910&amp;packageName=kernel" id="CVE-2024-35910&amp;packageName=kernel" title="CVE-2024-35910&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35932&amp;packageName=kernel" id="CVE-2024-35932&amp;packageName=kernel" title="CVE-2024-35932&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35935&amp;packageName=kernel" id="CVE-2024-35935&amp;packageName=kernel" title="CVE-2024-35935&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35937&amp;packageName=kernel" id="CVE-2024-35937&amp;packageName=kernel" title="CVE-2024-35937&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35951&amp;packageName=kernel" id="CVE-2024-35951&amp;packageName=kernel" title="CVE-2024-35951&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35965&amp;packageName=kernel" id="CVE-2024-35965&amp;packageName=kernel" title="CVE-2024-35965&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35966&amp;packageName=kernel" id="CVE-2024-35966&amp;packageName=kernel" title="CVE-2024-35966&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35982&amp;packageName=kernel" id="CVE-2024-35982&amp;packageName=kernel" title="CVE-2024-35982&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36016&amp;packageName=kernel" id="CVE-2024-36016&amp;packageName=kernel" title="CVE-2024-36016&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36916&amp;packageName=kernel" id="CVE-2024-36916&amp;packageName=kernel" title="CVE-2024-36916&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36917&amp;packageName=kernel" id="CVE-2024-36917&amp;packageName=kernel" title="CVE-2024-36917&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36919&amp;packageName=kernel" id="CVE-2024-36919&amp;packageName=kernel" title="CVE-2024-36919&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36928&amp;packageName=kernel" id="CVE-2024-36928&amp;packageName=kernel" title="CVE-2024-36928&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36952&amp;packageName=kernel" id="CVE-2024-36952&amp;packageName=kernel" title="CVE-2024-36952&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36954&amp;packageName=kernel" id="CVE-2024-36954&amp;packageName=kernel" title="CVE-2024-36954&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36960&amp;packageName=kernel" id="CVE-2024-36960&amp;packageName=kernel" title="CVE-2024-36960&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36968&amp;packageName=kernel" id="CVE-2024-36968&amp;packageName=kernel" title="CVE-2024-36968&amp;packageName=kernel" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36971&amp;packageName=kernel" id="CVE-2024-36971&amp;packageName=kernel" title="CVE-2024-36971&amp;packageName=kernel" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:afs: Fix corruption in reads at fpos 2G-4G from an OpenAFS serverAFS-3 has two data fetch RPC variants, FS.FetchData and FS.FetchData64, andLinux&#39;s afs client switches between them when talking to a non-YFS serverif the read size, the file position or the sum of the two have the upper 32bits set of the 64-bit value.This is a problem, however, since the file position and length fields ofFS.FetchData are *signed* 32-bit values.Fix this by capturing the capability bits obtained from the fileserver whenit&#39;s sent an FS.GetCapabilities RPC, rather than just discarding them, andthen picking out the VICED_CAPABILITY_64BITFILES flag.  This can then beused to decide whether to use FS.FetchData or FS.FetchData64 - and alsoFS.StoreData or FS.StoreData64 - rather than using upper_32_bits() toswitch on the parameter values.This capabilities flag could also be used to limit the maximum size of thefile, 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&#39;s also not a problem with Auristor servers as itsYFS.FetchData64 op uses unsigned 64-bit values.This can be tested by cloning a git repo through an OpenAFS client to anOpenAFS server and then doing &#34;git status&#34; on it from a Linux afsclient[1].  Provided the clone has a pack file that&#39;s in the 2G-4G range,the git status will show errors like:&#x9;error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match index&#x9;error: packfile .git/objects/pack/pack-5e813c51d12b6847bbc0fcd97c2bca66da50079c.pack does not match indexThis can be observed in the server&#39;s FileLog with something like thefollowing appearing:Sun Aug 29 19:31:39 2021 SRXAFS_FetchData, Fid = 2303380852.491776.3263114, Host 192.168.11.201:7001, Id 1001Sun Aug 29 19:31:39 2021 CheckRights: len=0, for host=192.168.11.201:7001Sun Aug 29 19:31:39 2021 FetchData_RXStyle: Pos 18446744071815340032, Len 3154Sun Aug 29 19:31:39 2021 FetchData_RXStyle: file size 2400758866...Sun Aug 29 19:31:40 2021 SRXAFS_FetchData returns 5Note the file position of 18446744071815340032.  This is the requested fileposition sign-extended.(CVE-2021-47366)In the Linux kernel, the following vulnerability has been resolved:net/smc: Fix possible access to freed memory in link clearAfter modifying the QP to the Error state, all RX WR would be completedwith WC in IB_WC_WR_FLUSH_ERR status. Current implementation does notwait 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-48673)In the Linux kernel, the following vulnerability has been resolved:soc: brcmstb: pm-arm: Fix refcount leak and __iomem leak bugsIn brcmstb_pm_probe(), there are two kinds of leak bugs:(1) we need to add of_node_put() when for_each__matching_node() breaks(2) we need to add iounmap() for each iomap in fail path(CVE-2022-48693)In the Linux kernel, the following vulnerability has been resolved:rpmsg: virtio: Free driver_override when rpmsg_remove()Free driver_override when rpmsg_remove(), otherwisethe following memory leak will occur:unreferenced object 0xffff0000d55d7080 (size 128):  comm &#34;kworker/u8:2&#34;, 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-2023-52670)In the Linux kernel, the following vulnerability has been resolved:pipe: wakeup wr_wait after setting max_usageCommit c73be61cede5 (&#34;pipe: Add general notification queue support&#34;) aregression was introduced that would lock up resized pipes under certainconditions. See the reproducer in [1].The commit resizing the pipe ring size was moved to a differentfunction, doing that moved the wakeup for pipe-&gt;wr_wait before actuallyraising pipe-&gt;max_usage. If a pipe was full before the resize occured itwould result in the wakeup never actually triggering pipe_write.Set @max_usage and @nr_accounted before waking writers if this isn&#39;t awatch queue.[Christian Brauner &lt;brauner@kernel.org&gt;: rewrite to account for watch queues](CVE-2023-52672)In the Linux kernel, the following vulnerability has been resolved:ACPI: video: check for error while searching for backlight device parentIf acpi_get_parent() called in acpi_video_dev_register_backlight()fails, for example, because acpi_ut_acquire_mutex() fails insideacpi_get_parent), this can lead to incorrect (uninitialized)acpi_parent handle being passed to acpi_get_pci_dev() for detectingthe 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-2023-52693)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&#39;t need to call mmc_remove_host(),or it will cause null-ptr-deref, because of deleting a not addeddevice in mmc_remove_host().To fix this, goto label &#39;fail_glue_init&#39;, if mmc_add_host() fails,and change the label &#39;fail_add_host&#39; to &#39;fail_gpiod_request&#39;.(CVE-2023-52708)In the Linux kernel, the following vulnerability has been resolved:ceph: blocklist the kclient when receiving corrupted snap traceWhen received corrupted snap trace we don&#39;t know what exactly hashappened in MDS side. And we shouldn&#39;t continue IOs and metadatasaccess to MDS, which may corrupt or get incorrect contents.This patch will just block all the further IO/MDS requestsimmediately and then evict the kclient itself.The reason why we still need to evict the kclient just afterblocking all the further IOs is that the MDS could revoke the capsfaster.(CVE-2023-52732)In the Linux kernel, the following vulnerability has been resolved:Fix page corruption caused by racy check in __free_pagesWhen we upgraded our kernel, we started seeing some page corruption likethe 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 pointerand cause crashes.After bisecting the issue, we found the issue started from commite320d3012d25 (&#34;mm/page_alloc.c: fix freeing non-compound pages&#34;):&#x9;if (put_page_testzero(page))&#x9;&#x9;free_the_page(page, order);&#x9;else if (!PageHead(page))&#x9;&#x9;while (order-- &gt; 0)&#x9;&#x9;&#x9;free_the_page(page + (1 &lt;&lt; order), order);So the problem is the check PageHead is racy because at this point wealready dropped our reference to the page.  So even if we came in withcompound page, the page can already be freed and PageHead can returnfalse and we will end up freeing all the tail pages causing double free.(CVE-2023-52739)In the Linux kernel, the following vulnerability has been resolved:IB/hfi1: Restore allocated resources on failed copyoutFix a resource leak if an error occurs.(CVE-2023-52747)In the Linux kernel, the following vulnerability has been resolved:virtio-blk: fix implicit overflow on virtio_max_dma_sizeThe 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. Oncevirtio_max_dma_size() has a larger size than U32_MAX, use U32_MAXinstead.(CVE-2023-52762)In the Linux kernel, the following vulnerability has been resolved:drm/panel: fix a possible null pointer dereferenceIn versatile_panel_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2023-52821)In the Linux kernel, the following vulnerability has been resolved:media: vidtv: mux: Add check and kfree for kstrdupAdd check for the return value of kstrdup() and return the errorif it fails in order to avoid NULL pointer dereference.Moreover, use kfree() in the later error handling in order to avoidmemory leak.(CVE-2023-52841)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 theskb and returns NULL.  Meanwhile on the success path, it returns theoriginal skb.  So it&#39;s straight forward to fix bug by using the returnedvalue.(CVE-2023-52846)In the Linux kernel, the following vulnerability has been resolved:clk: sunxi-ng: h6: Reparent CPUX during PLL CPUX rate changeWhile PLL CPUX clock rate change when CPU is running from it works invast majority of cases, now and then it causes instability. This leadsto system crashes and other undefined behaviour. After a lot of testing(30+ hours) while also doing a lot of frequency switches, we can&#39;tobserve any instability issues anymore when doing reparenting to stableclock like 24 MHz oscillator.(CVE-2023-52882)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_bufbefore validating request. But the fields in payload as well as smb2 headeris used in smb2_allocate_rsp_buf(). This patch add simple buffer sizevalidation to avoid potencial out-of-bounds in request buffer.(CVE-2024-26936)In the Linux kernel, the following vulnerability has been resolved:ARM: 9359/1: flush: check if the folio is reserved for no-mapping addressesSince commit a4d5613c4dc6 (&#34;arm: extend pfn_valid to take into accountfreed memory map alignment&#34;) changes the semantics of pfn_valid() to checkpresence of the memory map for a PFN. A valid page for an address whichis reserved but not mapped by the kernel[1], the system crashed duringsome uio test with the following memory layout: node   0: [mem 0x00000000c0a00000-0x00000000cc8fffff] node   0: [mem 0x00000000d0000000-0x00000000da1fffff] the uio layout is：0xc0900000, 0x100000the 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 exceptionSo check if PG_reserved was set to solve this issue.[1]: https://lore.kernel.org/lkml/Zbtdue57RO0QScJM@linux.ibm.com/(CVE-2024-26947)In the Linux kernel, the following vulnerability has been resolved:ksmbd: fix slab-out-of-bounds in smb_strndup_from_utf16()If -&gt;NameOffset of smb2_create_req is smaller than Buffer offset ofsmb2_create_req, slab-out-of-bounds read can happen from smb2_open.This patch set the minimum value of the name offset to the buffer offsetto validate name length of smb2_create_req().(CVE-2024-26954)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 andteardown a swap_info_struct while a call to free_swap_and_cache() wasrunning in another thread.  This could cause, amongst other badpossibilities, swap_page_trans_huge_swapped() (called byfree_swap_and_cache()) to access the freed memory for swap_map.This is a theoretical problem and I haven&#39;t been able to provoke it from atest case.  But there has been agreement based on code review that this ispossible (see link below).Fix it by using get_swap_device()/put_swap_device(), which will stallswapoff().  There was an extra check in _swap_info_get() to confirm thatthe swap entry was not free.  This isn&#39;t present in get_swap_device()because it doesn&#39;t make sense in general due to the race between gettingthe reference and swapoff.  So I&#39;ve added an equivalent check directly infree_swap_and_cache().Details of how to provoke one possible issue (thanks to David Hildenbrandfor deriving this):--8&lt;-----__swap_entry_free() might be the last user and result in&#34;count == SWAP_HAS_CACHE&#34;.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 turnsi-&gt;inuse_pages==0, before we completed swap_page_trans_huge_swapped().Imagine the following: 2 MiB folio in the swapcache. Only 2 subpages arestill 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_CACHEProcess 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 cachebut before process1 finished its call to swap_page_trans_huge_swapped()?--8&lt;-----(CVE-2024-26960)In the Linux kernel, the following vulnerability has been resolved:net/mlx5e: Prevent deadlock while disabling aRFSWhen disabling aRFS under the `priv-&gt;state_lock`, any scheduledaRFS 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 willtry to acquire the `state_lock` which is already acquired.The worker acquires the lock to delete the rules if the stateis down, which is not the worker&#39;s responsibility sincedisabling aRFS deletes the rules.Add an aRFS state variable, which indicates whether the aRFS isenabled and prevent adding rules when the aRFS is disabled.Kernel log:======================================================WARNING: possible circular locking dependency detected6.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/0x4e0but 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/0x4eother 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 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-0-gf21b5a4aeb02-prebuilt.qemu.org 04/01/2014Call 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-27014)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_objectslist in __nft_obj_type_get(). Therefore, there is potential data-raceof nf_tables_objects list entry.Use list_for_each_entry_rcu() to iterate over nf_tables_objectslist in __nft_obj_type_get(), and use rcu_read_lock() in the callernft_obj_type_get() to protect the entire type query process.(CVE-2024-27019)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential NULL pointer dereferences in &#39;dcn10_set_output_transfer_func()&#39;The &#39;stream&#39; pointer is used in dcn10_set_output_transfer_func() beforethe check if &#39;stream&#39; is NULL.Fixes the below:drivers/gpu/drm/amd/amdgpu/../display/dc/hwss/dcn10/dcn10_hwseq.c:1892 dcn10_set_output_transfer_func() warn: variable dereferenced before check &#39;stream&#39; (see line 1875)(CVE-2024-27044)In the Linux kernel, the following vulnerability has been resolved:net: ll_temac: platform_get_resource replaced by wrong functionThe function platform_get_resource was replaced withdevm_platform_ioremap_resource_byname and is called using 0 as name.This eventually ends up in platform_get_resource_byname in the callstack, where it causes a null pointer in strcmp.&#x9;if (type == resource_type(r) &amp;&amp; !strcmp(r-&gt;name, name))It should have been replaced with devm_platform_ioremap_resource.(CVE-2024-35796)In the Linux kernel, the following vulnerability has been resolved:fs/aio: Check IOCB_AIO_RW before the struct aio_kiocb conversionThe first kiocb_set_cancel_fn() argument may point at a struct kiocbthat is not embedded inside struct aio_kiocb. With the current code,depending on the compiler, the req-&gt;ki_ctx read happens either beforethe IOCB_AIO_RW test or after that test. Move the req-&gt;ki_ctx read suchthat it is guaranteed that the IOCB_AIO_RW test happens first.(CVE-2024-35815)In the Linux kernel, the following vulnerability has been resolved:soc: fsl: qbman: Use raw spinlock for cgr_locksmp_call_function always runs its callback in hard IRQ context, even onPREEMPT_RT, where spinlocks can sleep. So we need to use a raw spinlockfor cgr_lock to ensure we aren&#39;t waiting on a sleeping task.Although this bug has existed for a while, it was not apparent untilcommit ef2a8d5478b9 (&#34;net: dpaa: Adjust queue depth on rate change&#34;)which invokes smp_call_function_single via qman_update_cgr_safe everytime a link goes up or down.(CVE-2024-35819)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 ofcmdarray[i].cmdbuf fails, both cmdarray and cmdarray[i].cmdbuf needs tobe freed. Otherwise, there will be memleaks in lbs_allocate_cmd_buffer().(CVE-2024-35828)In the Linux kernel, the following vulnerability has been resolved:netfilter: bridge: replace physindev with physinif in nf_bridge_infoAn skb can be added to a neigh-&gt;arp_queue while waiting for an arpreply. Where original skb&#39;s skb-&gt;dev can be different to neigh&#39;sneigh-&gt;dev. For instance in case of bridging dnated skb from one veth toanother, 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 asthere is no explicit mechanism that prevents this physindev from beenfreed under us (for instance neigh_flush_dev doesn&#39;t cleanup skbs fromdifferent device&#39;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_finishLet&#39;s use plain ifindex instead of net_device link. To peek into theoriginal net_device we will use dev_get_by_index_rcu(). Thus either weget device and are safe to use it or we don&#39;t get it and drop skb.(CVE-2024-35839)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 thatis already being teared down by another thread that is executing__cifs_put_smb_ses().  This can happen when (a) the client hasconnection to the server but no session or (b) another thread ends upsetting @ses-&gt;ses_status again to something different thanSES_EXITING.To fix this, we need to make sure to unconditionally set@ses-&gt;ses_status to SES_EXITING and prevent any other threads fromsetting a new status while we&#39;re still tearing it down.The following can be reproduced by adding some delay to right afterthe ipc is freed in __cifs_put_smb_ses() - which will givesmb2_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/nullsleep 30kdestroy[reconnect srv]sleep 10umount /mnt/1...CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126CIFS: VFS: Verify user has a krb5 ticket and keyutils is installedCIFS: VFS: \\srv Send error in SessSetup = -126general protection fault, probably for non-canonical address0x6b6b6b6b6b6b6b6b: 0000 [#1] PREEMPT SMP NOPTICPU: 3 PID: 50 Comm: kworker/3:1 Not tainted 6.9.0-rc2 #1Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-1.fc3904/01/2014Workqueue: cifsiod smb2_reconnect_server [cifs]RIP: 0010:__list_del_entry_valid_or_report+0x33/0xf0Code: 4f 08 48 85 d2 74 42 48 85 c9 74 59 48 b8 00 01 00 00 00 00 adde 48 39 c2 74 61 48 b8 22 01 00 00 00 00 74 69 &lt;48&gt; 8b 01 48 39 f8 757b 48 8b 72 08 48 39 c6 0f 85 88 00 00 00 b8RSP: 0018:ffffc900001bfd70 EFLAGS: 00010a83RAX: dead000000000122 RBX: ffff88810da53838 RCX: 6b6b6b6b6b6b6b6bRDX: 6b6b6b6b6b6b6b6b RSI: ffffffffc02f6878 RDI: ffff88810da53800RBP: ffff88810da53800 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000001 R12: ffff88810c064000R13: 0000000000000001 R14: ffff88810c064000 R15: ffff8881039cc000FS: 0000000000000000(0000) GS:ffff888157c00000(0000)knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fe3728b1000 CR3: 000000010caa4000 CR4: 0000000000750ef0PKRU: 55555554Call 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-35870)In the Linux kernel, the following vulnerability has been resolved:ax25: fix use-after-free bugs caused by ax25_ds_del_timerWhen the ax25 device is detaching, the ax25_dev_device_down()calls ax25_ds_del_timer() to cleanup the slave_timer. Whenthe timer handler is running, the ax25_ds_del_timer() thatcalls del_timer() in it will return directly. As a result,the use-after-free bugs could happen, one of the scenariosis 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; //USEIn order to mitigate bugs, when the device is detaching, usetimer_shutdown_sync() to stop the timer.(CVE-2024-35887)In the Linux kernel, the following vulnerability has been resolved:tcp: properly terminate timers for kernel socketsWe had various syzbot reports about tcp timers firing afterthe 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 &#39;stop&#39; 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 timerholds a reference on the socket, and the user socket holdsa reference on the netns.For kernel sockets, we risk that the netns is freed beforetimer can complete, because kernel sockets do not holdreference on the netns.This patch adds inet_csk_clear_xmit_timers_sync() functionthat using sk_stop_timer_sync() to make sure all timersare 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 LOCKDEPsupport : inet_csk_clear_xmit_timers_sync() must not be calledwhile socket lock is held.It is very possible we can revert in the future commit3a58f13a881e (&#34;net: rds: acquire refcount on TCP sockets&#34;)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 fromtcp_out_of_resources() and __tcp_close() in the future.(CVE-2024-35910)In the Linux kernel, the following vulnerability has been resolved:drm/vc4: don&#39;t check if plane-&gt;state-&gt;fb == state-&gt;fbCurrently, when using non-blocking commits, we can see the followingkernel 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` areperfectly balanced, we cannot guarantee consistency in the checkplane-&gt;state-&gt;fb == state-&gt;fb. This means that sometimes we can increasethe refcount in `prepare_fb` and don&#39;t decrease it in `cleanup_fb`. Theopposite can also be true.In fact, the struct drm_plane .state shouldn&#39;t be accessed directlybut instead, the `drm_atomic_get_new_plane_state()` helper function shouldbe 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-35932)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 bufferfails. The pointers are not printed so we don&#39;t accidentally leak kerneladdresses.(CVE-2024-35935)In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: check A-MSDU format more carefullyIf it looks like there&#39;s another subframe in the A-MSDUbut the header isn&#39;t fully there, we can end up readingdata out of bounds, only to discard later. Make this abit more careful and check if the subframe header caneven be present.(CVE-2024-35937)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&#39;t release thepages ref we got earlier, otherwise we will end up with unbalancedget/put_pages() calls. We should instead leave everything in placeand let the BO release function deal with extra cleanup when the objectis destroyed, or let the fault handler try again next time it&#39;s called.(CVE-2024-35951)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: L2CAP: Fix not validating setsockopt user inputCheck user input length before copying data.(CVE-2024-35965)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: RFCOMM: Fix not validating setsockopt user inputsyzbot reported rfcomm_sock_setsockopt_old() is copying data withoutchecking user input length.BUG: KASAN: slab-out-of-bounds in copy_from_sockptr_offsetinclude/linux/sockptr.h:49 [inline]BUG: KASAN: slab-out-of-bounds in copy_from_sockptrinclude/linux/sockptr.h:55 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt_oldnet/bluetooth/rfcomm/sock.c:632 [inline]BUG: KASAN: slab-out-of-bounds in rfcomm_sock_setsockopt+0x893/0xa70net/bluetooth/rfcomm/sock.c:673Read of size 4 at addr ffff8880209a8bc3 by task syz-executor632/5064(CVE-2024-35966)In the Linux kernel, the following vulnerability has been resolved:batman-adv: Avoid infinite loop trying to resize local TTIf the MTU of one of an attached interface becomes too small to transmitthe local translation table then it must be resized to fit inside allfragments (when enabled) or a single packet.But if the MTU becomes too low to transmit even the header + the VLANspecific part then the resizing of the local TT will never succeed. Thiscan for example happen when the usable space is 110 bytes and 11 VLANs areon 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 thetimeout will be halved all the time and will then stagnate at 0 andtherefore never be able to reduce the table even more.There are other scenarios possible with a similar result. The number ofBATADV_TT_CLIENT_NOPURGE entries in the local TT can for example be toohigh to fit inside a packet. Such a scenario can therefore happen also withonly a single VLAN + 7 non-purgable addresses - requiring at least 120bytes.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 onlyconsuming 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 handlealso the situations when there were already incompatible systemconfiguration are present.(CVE-2024-35982)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 lessthan. Also add upper limit checks against the constant MAX_MRU ingsm0_receive() and gsm1_receive() to harden against memory corruption ofgsm-&gt;len and gsm-&gt;mru.All other checks remain as we still need to limit the data according to theuser configuration and actual payload size.(CVE-2024-36016)In the Linux kernel, the following vulnerability has been resolved:blk-iocost: avoid out of bounds shiftUBSAN catches undefined behavior in blk-iocost, where sometimesiocg-&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:23shift exponent 64 is too large for 64-bit type &#39;u64&#39; (aka &#39;unsigned long long&#39;)CPU: 16 PID: 0 Comm: swapper/16 Tainted: G S          E    N 6.9.0-0_fbk700_debug_rc2_kbuilder_0_gc85af715cac0 #1Hardware name: Quanta Twin Lakes MP/Twin Lakes Passive MP, BIOS F09_3A23 12/08/2020Call 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&#34;delay = 0&#34; branch if the shift is too large.I am not sure what the symptoms of an undefined valuedelay will be, but I suspect it could be more than alittle annoying to debug.(CVE-2024-36916)In the Linux kernel, the following vulnerability has been resolved:block: fix overflow in blk_ioctl_discard()There is no check for overflow of &#39;start + len&#39; in blk_ioctl_discard().Hung task occurs if submit an discard ioctl with the following param:  start = 0x80000000000ff000, len = 0x8000000000fff000;Add the overflow validation now.(CVE-2024-36917)In the Linux kernel, the following vulnerability has been resolved:scsi: bnx2fc: Remove spin_lock_bh while releasing resources after uploadThe session resources are used by FW and driver when session is offloaded,once session is uploaded these resources are not used. The lock is notrequired as these fields won&#39;t be used any longer. The offload and uploadcalls 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 #1Rebooting.[  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-36919)In the Linux kernel, the following vulnerability has been resolved:s390/qeth: Fix kernel panic after setting hsuidSymptom:When the hsuid attribute is set for the first time on an IQD Layer3device 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_ipv6nft_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 des_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].napiThe napi.poll functions are set during qeth_open().Sincecommit 1cfef80d4c2b (&#34;s390/qeth: Don&#39;t call dev_close/dev_open (DOWN/UP)&#34;)qeth_set_offline()/qeth_set_online() no longer call dev_close()/dev_open(). So if qeth_free_qdio_queues() clearedcard-&gt;qdio.out_qs[i].napi.poll while the network interface was UP and thecard was offline, they are not set again.Reproduction:chzdev -e $devno layer2=0ip link set dev $network_interface upecho 0 &gt; /sys/bus/ccw---truncated---(CVE-2024-36928)In the Linux kernel, the following vulnerability has been resolved:scsi: lpfc: Move NPIV&#39;s transport unregistration to after resource clean upThere are cases after NPIV deletion where the fabric switch still believesthe NPIV is logged into the fabric.  This occurs when a vport isunregistered before the Remove All DA_ID CT and LOGO ELS are sent to thefabric.Currently fc_remove_host(), which calls dev_loss_tmo for all D_IDs includingthe fabric D_ID, removes the last ndlp reference and frees the ndlp rportobject.  This sometimes causes the race condition where the final DA_ID andLOGO are skipped from being sent to the fabric switch.Fix by moving the fc_remove_host() and scsi_remove_host() calls after DA_IDand LOGO are sent.(CVE-2024-36952)In the Linux kernel, the following vulnerability has been resolved:tipc: fix a possible memleak in tipc_buf_append__skb_linearize() doesn&#39;t free the skb when it fails, so move&#39;*buf = NULL&#39; after __skb_linearize(), so that the skb can befreed on the err path.(CVE-2024-36954)In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix invalid reads in fence signaled eventsCorrectly set the length of the drm_event to the size of the structurethat&#39;s actually used.The length of the drm_event was set to the parent structure instead ofto the drm_vmw_event_fence which is supposed to be read. drm_readuses the length parameter to copy the event to the user space thusresuling in oob reads.(CVE-2024-36960)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 integeroverflow 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 connectionprocess earlier if MTU is invalid.Also, add a missing validation in read_buffer_size() and make it returnan error value if the validation fails.Now hci_conn_add() returns ERR_PTR() as it can fail due to the both akzalloc failure and invalid MTU value.divide error: 0000 [#1] PREEMPT SMP KASAN NOPTICPU: 0 PID: 67 Comm: kworker/u5:0 Tainted: G        W          6.9.0-rc5+ #20Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Workqueue: hci0 hci_rx_workRIP: 0010:l2cap_le_flowctl_init+0x19e/0x3f0 net/bluetooth/l2cap_core.c:547Code: e8 17 17 0c 00 66 41 89 9f 84 00 00 00 bf 01 00 00 00 41 b8 02 00 00 00 4c89 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 8db7 88 00 00 00 4c 89 f0 48 c1 e8 03 42RSP: 0018:ffff88810bc0f858 EFLAGS: 00010246RAX: 00000000000002a0 RBX: 0000000000000000 RCX: dffffc0000000000RDX: 0000000000000000 RSI: ffff88810bc0f7c0 RDI: ffffc90002dcb66fRBP: ffff88810bc0f880 R08: aa69db2dda70ff01 R09: 0000ffaaaaaaaaaaR10: 0084000000ffaaaa R11: 0000000000000000 R12: ffff88810d65a084R13: dffffc0000000000 R14: 00000000000002a0 R15: ffff88810d65a000FS:  0000000000000000(0000) GS:ffff88811ac00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020000100 CR3: 0000000103268003 CR4: 0000000000770ef0PKRU: 55555554Call 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-2024-36968)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-36971)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.80.0.160.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.80.0.160.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1755</id>
          <title>An update for aspell is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-25051" id="CVE-2019-25051" title="CVE-2019-25051" type="cve"></reference>
          </references>
          <description>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).(CVE-2019-25051)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="12" arch="aarch64" name="aspell-devel" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-devel-0.60.6.1-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="aspell-help" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-help-0.60.6.1-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="aspell-debugsource" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-debugsource-0.60.6.1-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="aspell-debuginfo" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-debuginfo-0.60.6.1-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="aarch64" name="aspell" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-0.60.6.1-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="aspell-debugsource" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-debugsource-0.60.6.1-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="aspell-help" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-help-0.60.6.1-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="aspell-debuginfo" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-debuginfo-0.60.6.1-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="aspell-devel" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-devel-0.60.6.1-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="12" arch="x86_64" name="aspell" release="30.oe2203sp1" version="0.60.6.1">
                         <filename>aspell-0.60.6.1-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1756</id>
          <title>An update for wget is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38428" id="CVE-2024-38428" title="CVE-2024-38428" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-38428)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="wget-debuginfo" release="5.oe2203sp1" version="1.21.2">
                         <filename>wget-debuginfo-1.21.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wget" release="5.oe2203sp1" version="1.21.2">
                         <filename>wget-1.21.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wget-help" release="5.oe2203sp1" version="1.21.2">
                         <filename>wget-help-1.21.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="wget-debugsource" release="5.oe2203sp1" version="1.21.2">
                         <filename>wget-debugsource-1.21.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wget-help" release="5.oe2203sp1" version="1.21.2">
                         <filename>wget-help-1.21.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wget-debuginfo" release="5.oe2203sp1" version="1.21.2">
                         <filename>wget-debuginfo-1.21.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wget-debugsource" release="5.oe2203sp1" version="1.21.2">
                         <filename>wget-debugsource-1.21.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="wget" release="5.oe2203sp1" version="1.21.2">
                         <filename>wget-1.21.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1757</id>
          <title>An update for giflib is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2020-23922" id="CVE-2020-23922" title="CVE-2020-23922" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-48161" id="CVE-2023-48161" title="CVE-2023-48161" type="cve"></reference>
          </references>
          <description>An issue was discovered in giflib through 5.1.4. DumpScreen2RGB in gif2rgb.c has a heap-based buffer over-read.(CVE-2020-23922)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(CVE-2023-48161)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="giflib" release="1.oe2203sp1" version="5.2.2">
                         <filename>giflib-5.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="giflib-devel" release="1.oe2203sp1" version="5.2.2">
                         <filename>giflib-devel-5.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="giflib-utils" release="1.oe2203sp1" version="5.2.2">
                         <filename>giflib-utils-5.2.2-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="giflib-help" release="1.oe2203sp1" version="5.2.2">
                         <filename>giflib-help-5.2.2-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib" release="1.oe2203sp1" version="5.2.2">
                         <filename>giflib-5.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib-devel" release="1.oe2203sp1" version="5.2.2">
                         <filename>giflib-devel-5.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="giflib-utils" release="1.oe2203sp1" version="5.2.2">
                         <filename>giflib-utils-5.2.2-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1758</id>
          <title>An update for cups is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35235" id="CVE-2024-35235" title="CVE-2024-35235" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-35235)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="cups-debugsource" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debuginfo" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-ipptool" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-libs" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-printerapp" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-lpd" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-devel" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-client" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-filesystem" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-filesystem-2.4.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-help" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-help-2.4.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-lpd" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debuginfo" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-ipptool" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-client" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debugsource" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-devel" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-libs" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-printerapp" release="11.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1760</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3341" id="CVE-2022-3341" title="CVE-2022-3341" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51798" id="CVE-2023-51798" title="CVE-2023-51798" type="cve"></reference>
          </references>
          <description>A null pointer dereference issue was discovered in &#39;FFmpeg&#39; in decode_main_header() function of libavformat/nutdec.c file. The flaw occurs because the function lacks check of the return value of avformat_new_stream() and triggers the null pointer dereference error, causing an application to crash.(CVE-2022-3341)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-2023-51798)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg-devel" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="8.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="8.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="8.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1763</id>
          <title>An update for rubygem-activesupport is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23633" id="CVE-2022-23633" title="CVE-2022-23633" type="cve"></reference>
          </references>
          <description>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-2022-23633)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport-doc" release="8.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activesupport-doc-6.1.4.1-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport" release="8.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activesupport-6.1.4.1-8.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1768</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47381" id="CVE-2021-47381" title="CVE-2021-47381" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47427" id="CVE-2021-47427" title="CVE-2021-47427" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47469" id="CVE-2021-47469" title="CVE-2021-47469" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39180" id="CVE-2023-39180" title="CVE-2023-39180" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52696" id="CVE-2023-52696" title="CVE-2023-52696" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52791" id="CVE-2023-52791" title="CVE-2023-52791" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52853" id="CVE-2023-52853" title="CVE-2023-52853" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26592" id="CVE-2024-26592" title="CVE-2024-26592" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26852" id="CVE-2024-26852" title="CVE-2024-26852" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26921" id="CVE-2024-26921" title="CVE-2024-26921" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26935" id="CVE-2024-26935" title="CVE-2024-26935" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26988" id="CVE-2024-26988" title="CVE-2024-26988" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27032" id="CVE-2024-27032" title="CVE-2024-27032" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27038" id="CVE-2024-27038" title="CVE-2024-27038" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27047" id="CVE-2024-27047" title="CVE-2024-27047" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27052" id="CVE-2024-27052" title="CVE-2024-27052" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27053" id="CVE-2024-27053" title="CVE-2024-27053" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27417" id="CVE-2024-27417" title="CVE-2024-27417" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31076" id="CVE-2024-31076" title="CVE-2024-31076" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35811" id="CVE-2024-35811" title="CVE-2024-35811" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35817" id="CVE-2024-35817" title="CVE-2024-35817" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35830" id="CVE-2024-35830" title="CVE-2024-35830" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35947" id="CVE-2024-35947" title="CVE-2024-35947" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36969" id="CVE-2024-36969" title="CVE-2024-36969" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36978" id="CVE-2024-36978" title="CVE-2024-36978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38538" id="CVE-2024-38538" title="CVE-2024-38538" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38545" id="CVE-2024-38545" title="CVE-2024-38545" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38549" id="CVE-2024-38549" title="CVE-2024-38549" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38555" id="CVE-2024-38555" title="CVE-2024-38555" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38569" id="CVE-2024-38569" title="CVE-2024-38569" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38591" id="CVE-2024-38591" title="CVE-2024-38591" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38601" id="CVE-2024-38601" title="CVE-2024-38601" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38634" id="CVE-2024-38634" title="CVE-2024-38634" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38662" id="CVE-2024-38662" title="CVE-2024-38662" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ASoC: SOF: Fix DSP oops stack dump output contentsFix @buf arg given to hex_dump_to_buffer() and stack address usedin dump error output.(CVE-2021-47381)In the Linux kernel, the following vulnerability has been resolved:scsi: iscsi: Fix iscsi_task use after freeCommit d39df158518c (&#34;scsi: iscsi: Have abort handler get ref to conn&#34;)added iscsi_get_conn()/iscsi_put_conn() calls during abort handling butthen also changed the handling of the case where we detect an alreadycompleted task where we now end up doing a goto to the common put/cleanupcode. This results in a iscsi_task use after free, because the commoncleanup code will do a put on the iscsi_task.This reverts the goto and moves the iscsi_get_conn() to after we&#39;ve checkedif the iscsi_task is valid.(CVE-2021-47427)In the Linux kernel, the following vulnerability has been resolved:spi: Fix deadlock when adding SPI controllers on SPI busesCurrently we have a global spi_add_lock which we take when adding newdevices so that we can check that we&#39;re not trying to reuse a chipselect that&#39;s already controlled.  This means that if the SPI device isitself a SPI controller and triggers the instantiation of further SPIdevices we trigger a deadlock as we try to register and instantiatethose devices while in the process of doing so for the parent controllerand hence already holding the global spi_add_lock.  Since we only careabout concurrency within a single SPI bus move the lock to be percontroller, avoiding the deadlock.This can be easily triggered in the case of spi-mux.(CVE-2021-47469)(CVE-2023-39180)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 memorywhich can be NULL upon failure.(CVE-2023-52696)In the Linux kernel, the following vulnerability has been resolved:i2c: core: Run atomic i2c xfer when !preemptibleSince bae1d3a05a8b, i2c transfers are non-atomic if preemption isdisabled. However, non-atomic i2c transfers require preemption (e.g. inwait_for_completion() while waiting for the DMA).panic() calls preempt_disable_notrace() before callingemergency_restart(). Therefore, if an i2c device is used for therestart, 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/0x32cUse !preemptible() instead, which is basically the same check aspre-v5.2.(CVE-2023-52791)In the Linux kernel, the following vulnerability has been resolved:hid: cp2112: Fix duplicate workqueue initializationPreviously the cp2112 driver called INIT_DELAYED_WORK withincp2112_gpio_irq_startup, resulting in duplicate initilizations of theworkqueue on subsequent IRQ startups following an initial request. Thisresulted in a warning in set_work_data in workqueue.c, as well as a rareNULL dereference within process_one_work in workqueue.c.Initialize the workqueue within _probe instead.(CVE-2023-52853)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-26592)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 (&#34;net/ipv6: prevent use after free inip6_route_mpath_notify&#34;) was not able to fix the root cause.We need to defer the fib6_info_release() calls afterip6_route_mpath_notify(), in the cleanup phase.[1]BUG: KASAN: slab-use-after-free in rt6_fill_node+0x1460/0x1ac0Read of size 4 at addr ffff88809a07fc64 by task syz-executor.2/23037CPU: 0 PID: 23037 Comm: syz-executor.2 Not tainted 6.8.0-rc4-syzkaller-01035-gea7f3cfaa588 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Call 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/0x77RIP: 0033:0x7f73dd87dda9Code: 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 48RSP: 002b:00007f73de6550c8 EFLAGS: 00000246 ORIG_RAX: 000000000000002eRAX: ffffffffffffffda RBX: 00007f73dd9ac050 RCX: 00007f73dd87dda9RDX: 0000000000000000 RSI: 0000000020000140 RDI: 0000000000000005RBP: 00007f73dd8ca47a R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 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/0x77Freed 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-2024-26852)In the Linux kernel, the following vulnerability has been resolved:inet: inet_defrag: prevent sk release while still in useip_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 callreturns, the sk must not be released.This affects skb fragments reassembled via netfilter or similarmodules, 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 (&#34;inet: frag: Always orphan skbs inside ip_defrag()&#34;)  [..]  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 copyhead-&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 thefully 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 theoffset into the FRAG_CB, else skb-&gt;sk gets clobbered.This allows to delay the orphaning long enough to learn if the skb hasto be queued or if the skb is completing the reasm queue.In the former case, things work as before, skb is orphaned.  This issafe because skb gets queued/stolen and won&#39;t continue past reasm engine.In the latter case, we will steal the skb-&gt;sk reference, reattach it tothe head skb, and fix up wmem accouting when inet_frag inflates truesize.(CVE-2024-26921)In the Linux kernel, the following vulnerability has been resolved:scsi: core: Fix unremoved procfs host directory regressionCommit fc663711b944 (&#34;scsi: core: Remove the /proc/scsi/${proc_name}directory earlier&#34;) fixed a bug related to modules loading/unloading, byadding a call to scsi_proc_hostdir_rm() on scsi_remove_host(). But that ledto a potential duplicate call to the hostdir_rm() routine, since it&#39;s alsocalled from scsi_host_dev_release(). That triggered a regression report,which was then fixed by commit be03df3d4bfe (&#34;scsi: core: Fix a procfs hostdirectory removal regression&#34;). The fix just dropped the hostdir_rm() callfrom dev_release().But it happens that this proc directory is created on scsi_host_alloc(),and that function &#34;pairs&#34; with scsi_host_dev_release(), whilescsi_remove_host() pairs with scsi_add_host(). In other words, it seems thereason for removing the proc directory on dev_release() was meant to covercases in which a SCSI host structure was allocated, but the call toscsi_add_host() didn&#39;t happen. And that pattern happens to exist in someerror paths, for example.Syzkaller causes that by using USB raw gadget device, error&#39;ing onusb-storage driver, at usb_stor_probe2(). By checking that path, we can seethat the BadDevice label leads to a scsi_host_put() after a SCSI hostallocation, but there&#39;s no call to scsi_add_host() in such path. That leadsto messages like this in dmesg (and a leak of the SCSI host procstructure):usb-storage 4-1:87.51: USB Mass Storage device detectedproc_dir_entry &#39;scsi/usb-storage&#39; already registeredWARNING: CPU: 1 PID: 3519 at fs/proc/generic.c:377 proc_register+0x347/0x4e0 fs/proc/generic.c:376The 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 acomment in scsi_host_dev_release() detailing that: such conditional ismeant 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-storagedoes not trigger the warning anymore.(CVE-2024-26935)In the Linux kernel, the following vulnerability has been resolved:init/main.c: Fix potential static_command_line memory overflowWe allocate memory of size &#39;xlen + strlen(boot_command_line) + 1&#39; forstatic_command_line, but the strings copied into static_command_line areextra_command_line and command_line, rather than extra_command_line andboot_command_line.When strlen(command_line) &gt; strlen(boot_command_line), static_command_linewill overflow.This patch just recovers strlen(command_line) which was miss-consolidatedwith strlen(boot_command_line) in the commit f5c7310ac73e (&#34;init/main: addchecks for the return value of memblock_alloc*()&#34;)(CVE-2024-26988)In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to avoid potential panic during recoveryDuring recovery, if FAULT_BLOCK is on, it is possible thatf2fs_reserve_new_block() will return -ENOSPC during recovery,then it may trigger panic.Also, if fault injection rate is 1 and only FAULT_BLOCK faulttype is on, it may encounter deadloop in loop of block reservation.Let&#39;s change as below to fix these issues:- remove bug_on() to avoid panic.- limit the loop count of block reservation to avoid potentialdeadloop.(CVE-2024-27032)In the Linux kernel, the following vulnerability has been resolved:clk: Fix clk_core_get NULL dereferenceIt is possible for clk_core_get to dereference a NULL in the followingsequence: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() athw-&gt;core.Prior to commit dde4eff47c82 (&#34;clk: Look for parents with clkdev basedclk_lookups&#34;) the check IS_ERR_OR_NULL() was performed which would havecaught the NULL.Reading the description of this function it talks about returning NULL butthat cannot be so at the moment.Update the function to check for hw before dereferencing it and return NULLif hw is NULL.(CVE-2024-27038)In the Linux kernel, the following vulnerability has been resolved:net: phy: fix phy_get_internal_delay accessing an empty arrayThe phy_get_internal_delay function could try to access to an emptyarray in the case that the driver is calling phy_get_internal_delaywithout defining delay_values and rx-internal-delay-ps ortx-internal-delay-ps is defined to 0 in the device-tree.This will lead to &#34;unable to handle kernel NULL pointer dereference atvirtual address 0&#34;. To avoid this kernel oops, the test should be delay&gt;= 0. As there is already delay &lt; 0 test just before, the test couldonly be size == 0.(CVE-2024-27047)In the Linux kernel, the following vulnerability has been resolved:wifi: rtl8xxxu: add cancel_work_sync() for c2hcmd_workThe workqueue might still be running, when the driver is stopped. Toavoid a use-after-free, call cancel_work_sync() in rtl8xxxu_stop().(CVE-2024-27052)In the Linux kernel, the following vulnerability has been resolved:wifi: wilc1000: fix RCU usage in connect pathWith lockdep enabled, calls to the connect function from cfg802.11 layerlead to the following warning:=============================WARNING: suspicious RCU usage6.7.0-rc1-wt+ #333 Not tainted-----------------------------drivers/net/wireless/microchip/wilc1000/hif.c:386suspicious rcu_dereference_check() usage![...]stack backtrace:CPU: 0 PID: 100 Comm: wpa_supplicant Not tainted 6.7.0-rc1-wt+ #333Hardware 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/0x1cThis warning is emitted because in the connect path, when trying to parsetarget BSS parameters, we dereference a RCU pointer whithout being in RCUcritical section.Fix RCU dereference usage by moving it to a RCU read critical section. Toavoid wrapping the whole wilc_parse_join_bss_param under the criticalsection, just use the critical section to copy ies data(CVE-2024-27053)In the Linux kernel, the following vulnerability has been resolved:ipv6: fix potential &#34;struct net&#34; leak in inet6_rtm_getaddr()It seems that if userspace provides a correct IFA_TARGET_NETNSID valuebut no IFA_ADDRESS and IFA_LOCAL attributes, inet6_rtm_getaddr()returns -EINVAL with an elevated &#34;struct net&#34; refcount.(CVE-2024-27417)In the Linux kernel, the following vulnerability has been resolved:genirq/cpuhotplug, x86/vector: Prevent vector leak during CPU offlineThe absence of IRQD_MOVE_PCNTXT prevents immediate effectiveness ofinterrupt affinity reconfiguration via procfs. Instead, the change isdeferred until the next instance of the interrupt being triggered on theoriginal CPU.When the interrupt next triggers on the original CPU, the new affinity isenforced within __irq_move_irq(). A vector is allocated from the new CPU,but the old vector on the original CPU remains and is not immediatelyreclaimed. Instead, apicd-&gt;move_in_progress is flagged, and the reclaimingprocess 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&#39;s vector_cleanup list if itremains online. Subsequently, the timer on the old CPU iterates over itsvector_cleanup list, reclaiming old vectors.However, a rare scenario arises if the old CPU is outgoing before theinterrupt triggers again on the new CPU.In that case irq_force_complete_move() is not invoked on the outgoing CPUto reclaim the old apicd-&gt;prev_vector because the interrupt isn&#39;t currentlyaffine to the outgoing CPU, and irq_needs_fixup() returns false. Eventhough __vector_schedule_cleanup() is later called on the new CPU, itdoesn&#39;t reclaim apicd-&gt;prev_vector; instead, it simply resets bothapicd-&gt;move_in_progress and apicd-&gt;prev_vector to 0.As a result, the vector remains unreclaimed in vector_matrix, leading to aCPU 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 theinterrupt 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 seeapicd-&gt;move_in_progress with apicd-&gt;prev_cpu pointing to an offline CPU.(CVE-2024-31076)In the Linux kernel, the following vulnerability has been resolved:wifi: brcmfmac: Fix use-after-free bug in brcmf_cfg80211_detachThis is the candidate patch of CVE-2023-47233 :https://nvd.nist.gov/vuln/detail/CVE-2023-47233In brcm80211 driver,it starts with the following invoking chainto 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,&#x9;&#x9;  brcmf_cfg80211_escan_timeout_worker);If we disconnect the USB by hotplug, it will callbrcmf_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 causea use-after-free bug on cfg in brcmf_cfg80211_escan_timeout_worker.Fix it by deleting the timer and canceling the worker inbrcmf_cfg80211_detach.[arend.vanspriel@broadcom.com: keep timer delete as is and cancel work just before free](CVE-2024-35811)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: amdgpu_ttm_gart_bind set gtt bound flagOtherwise after the GTT bo is released, the GTT and gart space is freedbut amdgpu_ttm_backend_unbind will not clear the gart page table entryand leave valid mapping entry pointing to the stale system page. Thenif GPU access the gart address mistakely, it will read undefined valueinstead page fault, harder to debug and reproduce the real issue.(CVE-2024-35817)In the Linux kernel, the following vulnerability has been resolved:media: tc358743: register v4l2 async device only after successful setupEnsure the device has been setup correctly before registering the v4l2async device, thus allowing userspace to access.(CVE-2024-35830)In the Linux kernel, the following vulnerability has been resolved:dyndbg: fix old BUG_ON in &gt;control parserFix a BUG_ON from 2009.  Even if it looks &#34;unreachable&#34; (I didn&#39;treally look), lets make sure by removing it, doing pr_err and return-EINVAL instead.(CVE-2024-35947)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix division by zero in setup_dsc_configWhen slice_height is 0, the division by slice_height in the calculationof the number of slices will cause a division by zero driver crash. Thisleaves the kernel in a state that requires a reboot. This patch adds acheck to avoid the division by zero.The stack trace below is for the 6.8.4 Kernel. I reproduced the issue ona Z16 Gen 2 Lenovo Thinkpad with a Apple Studio Display monitorconnected via Thunderbolt. The amdgpu driver crashed with this exceptionwhen 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) amdgpukernel: ? 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) amdgpukernel: ? 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) amdgpukernel: ? 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) amdgpukernel: dc_dsc_compute_config (drivers/gpu/drm/amd/amdgpu/../display/dc/dsc/dc_dsc.c:1109) amdgpuAfter applying this patch, the driver no longer crashes when the monitoris connected and the system is rebooted. I believe this is the sameissue reported for 3113.(CVE-2024-36969)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 logicafter kmalloc. So the old q-&gt;bands should not be used in kmalloc.Otherwise, an out-of-bounds write will occur.(CVE-2024-36978)In the Linux kernel, the following vulnerability has been resolved:net: bridge: xmit: make sure we have at least eth header len bytessyzbot triggered an uninit value[1] error in bridge device&#39;s xmit pathby sending a short (less than ETH_HLEN bytes) skb. To fix it check ifwe 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-38538)In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Fix UAF for cq async eventThe refcount of CQ is not protected by locks. When CQ asynchronousevents 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-38545)In the Linux kernel, the following vulnerability has been resolved:drm/mediatek: Add 0 size check to mtk_drm_gem_objAdd a check to mtk_drm_gem_init if we attempt to allocate a GEM objectof 0 bytes. Currently, no such check exists and the kernel will panic ifa userspace application attempts to allocate a 0x0 GBM buffer.Tested by attempting to allocate a 0x0 GBM buffer on an MT8188 andverifying that we now return EINVAL.(CVE-2024-38549)In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Discard command completions in internal errorFix use after free when FW completion arrives while device is ininternal error state. Avoid calling completion handler in this case,since the device will flush the command interface and trigger allcompletions 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/0xe0cmd_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/0xb0atomic_notifier_call_chain+0x16/0x20mlx5_eq_async_int+0xf6/0x290 [mlx5_core]notifier_call_chain+0x35/0xb0atomic_notifier_call_chain+0x16/0x20irq_int_handler+0x19/0x30 [mlx5_core]__handle_irq_event_percpu+0x4b/0x160handle_irq_event+0x2e/0x80handle_edge_irq+0x98/0x230__common_interrupt+0x3b/0xa0common_interrupt+0x7b/0xa0&lt;/IRQ&gt;&lt;TASK&gt;asm_common_interrupt+0x22/0x40(CVE-2024-38555)In the Linux kernel, the following vulnerability has been resolved:drivers/perf: hisi_pcie: Fix out-of-bound access when valid event groupThe perf tool allows users to create event groups through followingcmd [1], but the driver does not check whether the array index is out ofbounds when writing data to the event_group array. If the number of eventsin an event_group is greater than HISI_PCIE_MAX_COUNTERS, the memory writeoverflow 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 &#39;{pmu/event1/, ... ,pmu/event9/}&#39;(CVE-2024-38569)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-38591)In the Linux kernel, the following vulnerability has been resolved:ring-buffer: Fix a race between readers and resize checksThe reader code in rb_get_reader_page() swaps a new reader page into thering buffer by doing cmpxchg on old-&gt;list.prev-&gt;next to point it to thenew page. Following that, if the operation is successful,old-&gt;list.next-&gt;prev gets updated too. This means the underlyingdoubly-linked list is temporarily inconsistent, page-&gt;prev-&gt;next orpage-&gt;next-&gt;prev might not be equal back to page for some page in thering buffer.The resize operation in ring_buffer_resize() can be invoked in parallel.It calls rb_check_pages() which can detect the described inconsistencyand 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 parenttrace_buffer has recording disabled. Recent commit d78ab792705c(&#34;tracing: Stop current tracer when resizing buffer&#34;) causes that it isnow always the case which makes it more likely to experience this issue.The window to hit this race is nonetheless very small. To helpreproducing 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) &#x9;goto spin; for (unsigned i = 0; i &lt; 1U &lt;&lt; 26; i++)  /* inserted delay loop */ &#x9;__asm__ __volatile__ (&#34;&#34; : : : &#34;memory&#34;); rb_list_head(reader-&gt;list.next)-&gt;prev = &amp;cpu_buffer-&gt;reader_page-&gt;list;.. ---truncated---(CVE-2024-38601)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 atthe time of running. Make sure that it&#39;s taken by explicitly doingthat. 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-38634)In the Linux kernel, the following vulnerability has been resolved:bpf: Allow delete from sockmap/sockhash only if update is allowedWe have seen an influx of syzkaller reports where a BPF program attached toa tracepoint triggers a locking rule violation by performing a map_deleteon a sockmap/sockhash.We don&#39;t intend to support this artificial use scenario. Extend theexisting verifier allowed-program-type check for updating sockmap/sockhashto also cover deleting from a map.From now on only BPF programs which were previously allowed to updatesockmap/sockhash can delete from these map types.(CVE-2024-38662)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.82.0.163.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.82.0.163.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.82.0.163.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1772</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24789" id="CVE-2024-24789" title="CVE-2024-24789" type="cve"></reference>
          </references>
          <description>The archive/zip package&#39;s handling of certain types of invalid zip files differs from the behavior of most zip implementations. This misalignment could be exploited to create an zip file with contents that vary depending on the implementation reading the file. The archive/zip package now rejects files containing these errors.(CVE-2024-24789)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="34.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-34.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="34.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="34.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-34.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="34.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-34.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1773</id>
          <title>An update for poppler is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6239" id="CVE-2024-6239" title="CVE-2024-6239" type="cve"></reference>
          </references>
          <description>A flaw was found in the Poppler&#39;s Pdfinfo utility. This issue occurs when using -dests parameter with pdfinfo utility. By using certain malformed input files, an attacker could cause the utility to crash, leading to a denial of service.(CVE-2024-6239)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="poppler" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-utils" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-utils-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib-devel" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debugsource" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-devel" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-devel-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp-devel" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5-devel" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debuginfo" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-help" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-help-0.90.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-glib-doc" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-doc-0.90.0-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp-devel" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debuginfo" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-utils" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-utils-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5-devel" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-devel" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-devel-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debugsource" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib-devel" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler" release="8.oe2203sp1" version="0.90.0">
                         <filename>poppler-0.90.0-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1775</id>
          <title>An update for rubygem-actionview is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23913" id="CVE-2023-23913" title="CVE-2023-23913" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-23913)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rubygem-actionview-doc" release="2.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-actionview-doc-6.1.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-actionview" release="2.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-actionview-6.1.4.1-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1778</id>
          <title>An update for rubygem-actionpack is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-23633" id="CVE-2022-23633" title="CVE-2022-23633" type="cve"></reference>
          </references>
          <description>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-2022-23633)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack" release="6.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-actionpack-6.1.4.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-actionpack-doc" release="6.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-actionpack-doc-6.1.4.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1780</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-06-28"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35221" id="CVE-2024-35221" title="CVE-2024-35221" type="cve"></reference>
          </references>
          <description>Rubygems.org is the Ruby community&#39;s gem hosting service. A Gem publisher can cause a Remote DoS when publishing a Gem. This is due to how Ruby reads the Manifest of Gem files when using Gem::Specification.from_yaml. from_yaml makes use of SafeYAML.load which allows YAML aliases inside the YAML-based metadata of a gem. YAML aliases allow for Denial of Service attacks with so-called `YAML-bombs` (comparable to Billion laughs attacks). This was patched. There is is no action required by users. This issue is also tracked as GHSL-2024-001 and was discovered by the GitHub security lab.(CVE-2024-35221)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby-debugsource" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="135.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="135.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="135.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="135.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="135.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-135.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="135.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="135.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="135.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="135.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="135.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="135.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="135.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="135.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="135.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="135.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="135.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="135.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-135.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="135.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="135.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="135.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="135.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="135.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="135.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-135.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1783</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6387" id="CVE-2024-6387" title="CVE-2024-6387" type="cve"></reference>
          </references>
          <description>A signal handler race condition was found in OpenSSH&#39;s server (sshd), where a client does not authenticate within LoginGraceTime seconds (120 by default, 600 in old OpenSSH versions), then sshd&#39;s SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog().(CVE-2024-6387)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openssh" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debuginfo" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-server" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.31.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-help-8.8p1-31.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="31.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.31.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.31.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1785</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37894" id="CVE-2024-37894" title="CVE-2024-37894" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-37894)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="squid" release="25.oe2203sp1" version="4.9">
                         <filename>squid-4.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="squid-debuginfo" release="25.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="squid-debugsource" release="25.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="squid" release="25.oe2203sp1" version="4.9">
                         <filename>squid-4.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="squid-debuginfo" release="25.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="squid-debugsource" release="25.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1787</id>
          <title>An update for glib2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34397" id="CVE-2024-34397" title="CVE-2024-34397" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-34397)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glib2" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-2.72.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debuginfo" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-debugsource" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-devel" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-devel-2.72.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-static" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-static-2.72.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glib2-tests" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-tests-2.72.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glib2-help" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-help-2.72.2-15.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-2.72.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debuginfo" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-debuginfo-2.72.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-debugsource" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-debugsource-2.72.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-devel" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-devel-2.72.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-static" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-static-2.72.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glib2-tests" release="15.oe2203sp1" version="2.72.2">
                         <filename>glib2-tests-2.72.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1796</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35821" id="CVE-2024-35821" title="CVE-2024-35821" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35955" id="CVE-2024-35955" title="CVE-2024-35955" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36974" id="CVE-2024-36974" title="CVE-2024-36974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37356" id="CVE-2024-37356" title="CVE-2024-37356" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38541" id="CVE-2024-38541" title="CVE-2024-38541" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38556" id="CVE-2024-38556" title="CVE-2024-38556" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38564" id="CVE-2024-38564" title="CVE-2024-38564" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38588" id="CVE-2024-38588" title="CVE-2024-38588" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38599" id="CVE-2024-38599" title="CVE-2024-38599" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38623" id="CVE-2024-38623" title="CVE-2024-38623" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38624" id="CVE-2024-38624" title="CVE-2024-38624" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38630" id="CVE-2024-38630" title="CVE-2024-38630" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38661" id="CVE-2024-38661" title="CVE-2024-38661" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39292" id="CVE-2024-39292" title="CVE-2024-39292" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ubifs: Set page uptodate in the correct placePage cache reads are lockless, so setting the freshly allocated pageuptodate before we&#39;ve overwritten it with the data it&#39;s supposed to havein it will allow a simultaneous reader to see old data.  Move the callto SetPageUptodate into ubifs_write_end(), which is after we copied thenew data into the page.(CVE-2024-35821)In the Linux kernel, the following vulnerability has been resolved:kprobes: Fix possible use-after-free issue on kprobe registrationWhen unloading a module, its state is changing MODULE_STATE_LIVE -&gt; MODULE_STATE_GOING -&gt; MODULE_STATE_UNFORMED. Each change will takea 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 thenext one is failed because module-&gt;state becomes MODULE_STATE_UNFORMEDbetween 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 changedto MODULE_STATE_UNFORMED. In this case, arm_kprobe() will try to modifynon-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 withMODULE_STATE_LIVE.(CVE-2024-35955)In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: always validate TCA_TAPRIO_ATTR_PRIOMAPIf one TCA_TAPRIO_ATTR_PRIOMAP attribute has been provided,taprio_parse_mqprio_opt() must validate it, or userspacecan inject arbitrary data to the kernel, the second timetaprio_change() is called.First call (with valid attributes) sets dev-&gt;num_tcto a non zero value.Second call (with arbitrary mqprio attributes)returns early from taprio_parse_mqprio_opt()and bad things can happen.(CVE-2024-36974)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_gas 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 triggeredshift-out-of-bounds [0] by setting 100 to dctcp_shift_g:  memcpy((void*)0x20000080,         &#34;/sys/module/tcp_dctcp/parameters/dctcp_shift_g\000&#34;, 47);  res = syscall(__NR_openat, /*fd=*/0xffffffffffffff9cul, /*file=*/0x20000080ul,                /*flags=*/2ul, /*mode=*/0ul);  memcpy((void*)0x20000000, &#34;100\000&#34;, 4);  syscall(__NR_write, /*fd=*/r[0], /*val=*/0x20000000ul, /*len=*/4ul);Let&#39;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:12shift exponent 100 is too large for 32-bit type &#39;u32&#39; (aka &#39;unsigned int&#39;)CPU: 0 PID: 8083 Comm: syz-executor345 Not tainted 6.9.0-05151-g1b294a1f3561 #2Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS1.13.0-1ubuntu1.1 04/01/2014Call 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/0x6fRIP: 0033:0x7f6c2b5005b6Code: Unable to access opcode bytes at 0x7f6c2b50058c.RSP: 002b:00007ffe883eb948 EFLAGS: 00000246 ORIG_RAX: 00000000000000e7RAX: ffffffffffffffda RBX: 00007f6c2b5862f0 RCX: 00007f6c2b5005b6RDX: 0000000000000001 RSI: 000000000000003c RDI: 0000000000000001RBP: 0000000000000001 R08: 00000000000000e7 R09: ffffffffffffffc0R10: 0000000000000006 R11: 0000000000000246 R12: 00007f6c2b5862f0R13: 0000000000000001 R14: 0000000000000000 R15: 0000000000000001 &lt;/TASK&gt;(CVE-2024-37356)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 1stsnprintf() call, the len parameter will become negative and str parameter(if not NULL initially) will point beyond the buffer&#39;s end. Add the bufferoverflow check after the 1st snprintf() call and fix such check after thestrlen() call (accounting for the terminating NUL char).(CVE-2024-38541)In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Add a timeout to acquire the command queue semaphorePrevent forced completion handling on an entry that has not yet beenassigned an index, causing an out of bounds access on idx = -22.Instead of waiting indefinitely for the sem, blocking flow now waits forindex to be allocated or a sem acquisition timeout before beginning thetimer 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-2024-38556)In the Linux kernel, the following vulnerability has been resolved:bpf: Add BPF_PROG_TYPE_CGROUP_SKB attach type enforcement in BPF_LINK_CREATEbpf_prog_attach uses attach_type_to_prog_type to enforce properattach type for BPF_PROG_TYPE_CGROUP_SKB. link_create usesbpf_prog_get and relies on bpf_prog_attach_check_attach_typeto properly verify prog_type &lt;&gt; attach_type association.Add missing attach_type enforcement for the link_create case.Otherwise, it&#39;s currently possible to attach cgroup_skb progtypes to other cgroup hooks.(CVE-2024-38564)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/0x79The root cause is that, in lookup_rec(), ftrace record of some addressis being searched in ftrace pages of some module, but those ftrace pagesat the same time is being freed in ftrace_release_mod() as thecorresponding 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-2024-38588)In the Linux kernel, the following vulnerability has been resolved:jffs2: prevent xattr node from overflowing the eraseblockAdd a check to make sure that the requested xattr node size is no largerthan the eraseblock minus the cleanmarker.Unlike the usual inode nodes, the xattr nodes aren&#39;t split into partsand spread across multiple eraseblocks, which means that a xattr nodemust not occupy more than one eraseblock. If the requested xattr value istoo large, the xattr node can spill onto the next eraseblock, overwritingthe nodes and causing errors such as:jffs2: argh. node added in wrong place at 0x0000b050(2)jffs2: nextblock 0x0000a000, expected at 0000b00cjffs2: error: (823) do_verify_xattr_datum: node CRC failed at 0x01e050,read=0xfc892c93, calc=0x000000jffs2: notice: (823) jffs2_get_inode_nodes: Node header CRC failedat 0x01e00c. {848f,2fc4,0fef511f,59a3d171}jffs2: Node at 0x0000000c with length 0x00001044 would run over theend of the erase blockjffs2: Perhaps the file system was created with the wrong erase size?jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not foundat 0x00000010: 0x1044 insteadThis breaks the filesystem and can lead to KASAN crashes such as:BUG: KASAN: slab-out-of-bounds in jffs2_sum_add_kvec+0x125e/0x15d0Read of size 4 at addr ffff88802c31e914 by task repro/830CPU: 0 PID: 830 Comm: repro Not tainted 6.9.0-rc3+ #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),BIOS Arch Linux 1.16.3-1-1 04/01/2014Call 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-38599)In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Use variable length array instead of fixed sizeShould fix smatch warning:&#x9;ntfs_set_label() error: __builtin_memcpy() &#39;uni-&gt;name&#39; too small (20 vs 256)(CVE-2024-38623)In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Use 64 bit variable to avoid 32 bit overflowFor example, in the expression:&#x9;vbo = 2 * vbo + skip(CVE-2024-38624)In the Linux kernel, the following vulnerability has been resolved:watchdog: cpu5wdt.c: Fix use-after-free bug caused by cpu5wdt_triggerWhen the cpu5wdt module is removing, the origin code uses del_timer() tode-activate the timer. If the timer handler is running, del_timer() couldnot stop it and will return directly. If the port region is released byrelease_region() and then the timer handler cpu5wdt_trigger() calls outb()to write into the region that is released, the use-after-free bug willhappen.Change del_timer() to timer_shutdown_sync() in order that the timer handlercould be finished before the port region is released.(CVE-2024-38630)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_oopsoccured 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. Thecorrect checks are already in place in the function but a simple int forthe internal variables was used with the possibility to overflow.(CVE-2024-38661)In the Linux kernel, the following vulnerability has been resolved:um: Add winch to winch_handlers before registering winch IRQRegistering a winch IRQ is racy, an interrupt may occur before the winch isadded to the winch_handlers list.If that happens, register_winch_irq() adds to that list a winch that isscheduled to be (or has already been) freed, causing a panic later inwinch_cleanup().Avoid the race by adding the winch to the winch_handlers list beforeregistering the IRQ, and rolling back if um_request_irq() fails.(CVE-2024-39292)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.83.0.164.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.83.0.164.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.83.0.164.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1799</id>
          <title>An update for rubygem-activesupport is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-28120" id="CVE-2023-28120" title="CVE-2023-28120" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-28120)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport" release="8.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activesupport-6.1.4.1-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-activesupport-doc" release="8.oe2203sp1" version="6.1.4.1">
                         <filename>rubygem-activesupport-doc-6.1.4.1-8.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1801</id>
          <title>An update for python-pip is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3651" id="CVE-2024-3651" title="CVE-2024-3651" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-3651)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-pip-help" release="6.oe2203sp1" version="21.3.1">
                         <filename>python-pip-help-21.3.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-pip-wheel" release="6.oe2203sp1" version="21.3.1">
                         <filename>python-pip-wheel-21.3.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pip" release="6.oe2203sp1" version="21.3.1">
                         <filename>python3-pip-21.3.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1807</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-38171" id="CVE-2021-38171" title="CVE-2021-38171" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-3109" id="CVE-2022-3109" title="CVE-2022-3109" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50010" id="CVE-2023-50010" title="CVE-2023-50010" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-51793" id="CVE-2023-51793" title="CVE-2023-51793" type="cve"></reference>
          </references>
          <description>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-38171)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-2022-3109)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-2023-50010)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-51793)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="12.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="12.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="12.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1809</id>
          <title>An update for avro is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39410" id="CVE-2023-39410" title="CVE-2023-39410" type="cve"></reference>
          </references>
          <description>When deserializing untrusted or corrupted data, it is possible for a reader to consume memory beyond the allowed constraints and thus lead to out of memory on the system.This issue affects Java applications using Apache Avro Java SDK up to and including 1.11.2.  Users should update to apache-avro version 1.11.3 which addresses this issue.(CVE-2023-39410)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="avro" release="5.oe2203sp1" version="1.10.2">
                         <filename>avro-1.10.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avro" release="5.oe2203sp1" version="1.10.2">
                         <filename>avro-1.10.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1811</id>
          <title>An update for rust is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-05"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36113" id="CVE-2022-36113" title="CVE-2022-36113" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36114" id="CVE-2022-36114" title="CVE-2022-36114" type="cve"></reference>
          </references>
          <description>Cargo is a package manager for the rust programming language. After a package is downloaded, Cargo extracts its source code in the ~/.cargo folder on disk, making it available to the Rust projects it builds. To record when an extraction is successful, Cargo writes &#34;ok&#34; to the .cargo-ok file at the root of the extracted source code once it extracted all the files. It was discovered that Cargo allowed packages to contain a .cargo-ok symbolic link, which Cargo would extract. Then, when Cargo attempted to write &#34;ok&#34; into .cargo-ok, it would actually replace the first two bytes of the file the symlink pointed to with ok. This would allow an attacker to corrupt one file on the machine using Cargo to extract the package. Note that by design Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it&#39;s possible to perform the same attacks with build scripts and procedural macros. The vulnerability is present in all versions of Cargo. Rust 1.64, to be released on September 22nd, will include a fix for it. Since the vulnerability is just a more limited way to accomplish what a malicious build scripts or procedural macros can do, we decided not to publish Rust point releases backporting the security fix. Patch files are available for Rust 1.63.0 are available in the wg-security-response repository for people building their own toolchain.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-36113)Cargo is a package manager for the rust programming language. It was discovered that Cargo did not limit the amount of data extracted from compressed archives. An attacker could upload to an alternate registry a specially crafted package that extracts way more data than its size (also known as a &#34;zip bomb&#34;), exhausting the disk space on the machine using Cargo to download the package. Note that by design Cargo allows code execution at build time, due to build scripts and procedural macros. The vulnerabilities in this advisory allow performing a subset of the possible damage in a harder to track down way. Your dependencies must still be trusted if you want to be protected from attacks, as it&#39;s possible to perform the same attacks with build scripts and procedural macros. The vulnerability is present in all versions of Cargo. Rust 1.64, to be released on September 22nd, will include a fix for it. Since the vulnerability is just a more limited way to accomplish what a malicious build scripts or procedural macros can do, we decided not to publish Rust point releases backporting the security fix. Patch files are available for Rust 1.63.0 are available in the wg-security-response repository for people building their own toolchain. We recommend users of alternate registries to excercise care in which package they download, by only including trusted dependencies in their projects. Please note that even with these vulnerabilities fixed, by design Cargo allows arbitrary code execution at build time thanks to build scripts and procedural macros: a malicious dependency will be able to cause damage regardless of these vulnerabilities. crates.io implemented server-side checks to reject these kinds of packages years ago, and there are no packages on crates.io exploiting these vulnerabilities. crates.io users still need to excercise care in choosing their dependencies though, as the same concerns about build scripts and procedural macros apply here.(CVE-2022-36114)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cargo" release="4.oe2203sp1" version="1.60.0">
                         <filename>cargo-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clippy" release="4.oe2203sp1" version="1.60.0">
                         <filename>clippy-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rls" release="4.oe2203sp1" version="1.60.0">
                         <filename>rls-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-analysis" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-analysis-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-debuginfo" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-debuginfo-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-debugsource" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-debugsource-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-help" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-help-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rust-std-static" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-std-static-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rustfmt" release="4.oe2203sp1" version="1.60.0">
                         <filename>rustfmt-1.60.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-debugger-common" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-debugger-common-1.60.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-gdb" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-gdb-1.60.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-lldb" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-lldb-1.60.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rust-src" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-src-1.60.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cargo" release="4.oe2203sp1" version="1.60.0">
                         <filename>cargo-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clippy" release="4.oe2203sp1" version="1.60.0">
                         <filename>clippy-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rls" release="4.oe2203sp1" version="1.60.0">
                         <filename>rls-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-analysis" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-analysis-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-debuginfo" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-debuginfo-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-debugsource" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-debugsource-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-help" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-help-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rust-std-static" release="4.oe2203sp1" version="1.60.0">
                         <filename>rust-std-static-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rustfmt" release="4.oe2203sp1" version="1.60.0">
                         <filename>rustfmt-1.60.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1816</id>
          <title>An update for emacs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39331" id="CVE-2024-39331" title="CVE-2024-39331" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-39331)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="emacs" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-27.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="emacs-common" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-common-27.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="emacs-debuginfo" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-debuginfo-27.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="emacs-debugsource" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-debugsource-27.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="emacs-devel" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-devel-27.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="emacs-lucid" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-lucid-27.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="emacs-nox" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-nox-27.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="emacs-filesystem" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-filesystem-27.2-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="emacs-help" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-help-27.2-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="emacs-terminal" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-terminal-27.2-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="emacs" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-27.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="emacs-common" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-common-27.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="emacs-debuginfo" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-debuginfo-27.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="emacs-debugsource" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-debugsource-27.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="emacs-devel" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-devel-27.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="emacs-lucid" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-lucid-27.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="emacs-nox" release="14.oe2203sp1" version="27.2">
                         <filename>emacs-nox-27.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1818</id>
          <title>An update for xorg-x11-server-xwayland is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2320" id="CVE-2022-2320" title="CVE-2022-2320" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-2320)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debuginfo" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debugsource" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-devel" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debuginfo" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debugsource" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-devel" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1822</id>
          <title>An update for rubygem-rack is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44572" id="CVE-2022-44572" title="CVE-2022-44572" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26141" id="CVE-2024-26141" title="CVE-2024-26141" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-44572)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-26141)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-rack" release="4.oe2203sp1" version="2.2.3.1">
                         <filename>rubygem-rack-2.2.3.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-rack-help" release="4.oe2203sp1" version="2.2.3.1">
                         <filename>rubygem-rack-help-2.2.3.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1824</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35176" id="CVE-2024-35176" title="CVE-2024-35176" type="cve"></reference>
          </references>
          <description> REXML is an XML toolkit for Ruby. The REXML gem before 3.2.6 has a denial of service vulnerability when it parses an XML that has many `&lt;`s in an attribute value. Those who need to parse untrusted XMLs may be impacted to this vulnerability. The REXML gem 3.2.7 or later include the patch to fix this vulnerability. As a workaround, don&#39;t parse untrusted XMLs.(CVE-2024-35176)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="136.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="136.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="136.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="136.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="136.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-136.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="136.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="136.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="136.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="136.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="136.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="136.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="136.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="136.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="136.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="136.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="136.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="136.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-136.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="136.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="136.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="136.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="136.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="136.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="136.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-136.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1825</id>
          <title>An update for krb5 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37370" id="CVE-2024-37370" title="CVE-2024-37370" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37371" id="CVE-2024-37371" title="CVE-2024-37371" type="cve"></reference>
          </references>
          <description>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-37370)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.(CVE-2024-37371)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="krb5" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-1.19.2-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-client" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-client-1.19.2-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-debuginfo" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-debuginfo-1.19.2-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-debugsource" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-debugsource-1.19.2-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-devel" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-devel-1.19.2-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-libs" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-libs-1.19.2-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="krb5-server" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-server-1.19.2-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="krb5-help" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-help-1.19.2-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-1.19.2-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-client" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-client-1.19.2-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-debuginfo" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-debuginfo-1.19.2-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-debugsource" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-debugsource-1.19.2-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-devel" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-devel-1.19.2-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-libs" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-libs-1.19.2-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="krb5-server" release="17.oe2203sp1" version="1.19.2">
                         <filename>krb5-server-1.19.2-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1829</id>
          <title>An update for vte291 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37535" id="CVE-2024-37535" title="CVE-2024-37535" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-37535)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="vte291" release="2.oe2203sp1" version="0.62.3">
                         <filename>vte291-0.62.3-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vte291-debuginfo" release="2.oe2203sp1" version="0.62.3">
                         <filename>vte291-debuginfo-0.62.3-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vte291-debugsource" release="2.oe2203sp1" version="0.62.3">
                         <filename>vte291-debugsource-0.62.3-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vte291-devel" release="2.oe2203sp1" version="0.62.3">
                         <filename>vte291-devel-0.62.3-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vte291" release="2.oe2203sp1" version="0.62.3">
                         <filename>vte291-0.62.3-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vte291-debuginfo" release="2.oe2203sp1" version="0.62.3">
                         <filename>vte291-debuginfo-0.62.3-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vte291-debugsource" release="2.oe2203sp1" version="0.62.3">
                         <filename>vte291-debugsource-0.62.3-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vte291-devel" release="2.oe2203sp1" version="0.62.3">
                         <filename>vte291-devel-0.62.3-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1830</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38475" id="CVE-2024-38475" title="CVE-2024-38475" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39573" id="CVE-2024-39573" title="CVE-2024-39573" type="cve"></reference>
          </references>
          <description>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 &#34;UnsafePrefixStat&#34; can be used to opt back in once ensuring the substitution is appropriately constrained.(CVE-2024-38475)Potential SSRF in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows an attacker to cause unsafe RewriteRules to unexpectedly setup URL&#39;s to be handled by mod_proxy.Users are recommended to upgrade to version 2.4.60, which fixes this issue.(CVE-2024-39573)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="httpd" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_proxy_html" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ssl" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-help-2.4.51-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_proxy_html" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ssl" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1832</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-28429" id="CVE-2021-28429" title="CVE-2021-28429" type="cve"></reference>
          </references>
          <description>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-2021-28429)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="14.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="14.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="14.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1838</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47618" id="CVE-2021-47618" title="CVE-2021-47618" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48733" id="CVE-2022-48733" title="CVE-2022-48733" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48744" id="CVE-2022-48744" title="CVE-2022-48744" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48765" id="CVE-2022-48765" title="CVE-2022-48765" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48772" id="CVE-2022-48772" title="CVE-2022-48772" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52873" id="CVE-2023-52873" title="CVE-2023-52873" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35879" id="CVE-2024-35879" title="CVE-2024-35879" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35893" id="CVE-2024-35893" title="CVE-2024-35893" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35969" id="CVE-2024-35969" title="CVE-2024-35969" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35988" id="CVE-2024-35988" title="CVE-2024-35988" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35989" id="CVE-2024-35989" title="CVE-2024-35989" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36014" id="CVE-2024-36014" title="CVE-2024-36014" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36489" id="CVE-2024-36489" title="CVE-2024-36489" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37353" id="CVE-2024-37353" title="CVE-2024-37353" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37354" id="CVE-2024-37354" title="CVE-2024-37354" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38381" id="CVE-2024-38381" title="CVE-2024-38381" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38547" id="CVE-2024-38547" title="CVE-2024-38547" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38552" id="CVE-2024-38552" title="CVE-2024-38552" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38553" id="CVE-2024-38553" title="CVE-2024-38553" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38554" id="CVE-2024-38554" title="CVE-2024-38554" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38577" id="CVE-2024-38577" title="CVE-2024-38577" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38579" id="CVE-2024-38579" title="CVE-2024-38579" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38582" id="CVE-2024-38582" title="CVE-2024-38582" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38583" id="CVE-2024-38583" title="CVE-2024-38583" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38590" id="CVE-2024-38590" title="CVE-2024-38590" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38596" id="CVE-2024-38596" title="CVE-2024-38596" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38602" id="CVE-2024-38602" title="CVE-2024-38602" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38603" id="CVE-2024-38603" title="CVE-2024-38603" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38625" id="CVE-2024-38625" title="CVE-2024-38625" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38633" id="CVE-2024-38633" title="CVE-2024-38633" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38637" id="CVE-2024-38637" title="CVE-2024-38637" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38780" id="CVE-2024-38780" title="CVE-2024-38780" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39301" id="CVE-2024-39301" title="CVE-2024-39301" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39362" id="CVE-2024-39362" title="CVE-2024-39362" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39467" id="CVE-2024-39467" title="CVE-2024-39467" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ARM: 9170/1: fix panic when kasan and kprobe are enabledarm32 uses software to simulate the instruction replacedby kprobe. some instructions may be simulated by constructingassembly functions. therefore, before executing instructionsimulation, it is necessary to construct assembly functionexecution environment in C language through binding registers.after kasan is enabled, the register binding relationship willbe destroyed, resulting in instruction simulation errors andcausing kernel panic.the kprobe emulate instruction function is distributed in threefiles: actions-common.c actions-arm.c actions-thumb.c, so disableKASAN when compiling these files.for example, use kprobe insert on cap_capable+20 after kasanenabled, the cap_capable assembly code is as follows:&lt;cap_capable&gt;:e92d47f0&#x9;push&#x9;{r4, r5, r6, r7, r8, r9, sl, lr}e1a05000&#x9;mov&#x9;r5, r0e280006c&#x9;add&#x9;r0, r0, #108    ; 0x6ce1a04001&#x9;mov&#x9;r4, r1e1a06002&#x9;mov&#x9;r6, r2e59fa090&#x9;ldr&#x9;sl, [pc, #144]  ;ebfc7bf8&#x9;bl&#x9;c03aa4b4 &lt;__asan_load4&gt;e595706c&#x9;ldr&#x9;r7, [r5, #108]  ; 0x6ce2859014&#x9;add&#x9;r9, r5, #20......The emulate_ldr assembly code after enabling kasan is as follows:c06f1384 &lt;emulate_ldr&gt;:e92d47f0&#x9;push&#x9;{r4, r5, r6, r7, r8, r9, sl, lr}e282803c&#x9;add&#x9;r8, r2, #60     ; 0x3ce1a05000&#x9;mov&#x9;r5, r0e7e37855&#x9;ubfx&#x9;r7, r5, #16, #4e1a00008&#x9;mov&#x9;r0, r8e1a09001&#x9;mov&#x9;r9, r1e1a04002&#x9;mov&#x9;r4, r2ebf35462&#x9;bl&#x9;c03c6530 &lt;__asan_load4&gt;e357000f&#x9;cmp&#x9;r7, #15e7e36655&#x9;ubfx&#x9;r6, r5, #12, #4e205a00f&#x9;and&#x9;sl, r5, #150a000001&#x9;beq&#x9;c06f13bc &lt;emulate_ldr+0x38&gt;e0840107&#x9;add&#x9;r0, r4, r7, lsl #2ebf3545c&#x9;bl&#x9;c03c6530 &lt;__asan_load4&gt;e084010a&#x9;add&#x9;r0, r4, sl, lsl #2ebf3545a&#x9;bl&#x9;c03c6530 &lt;__asan_load4&gt;e2890010&#x9;add&#x9;r0, r9, #16ebf35458&#x9;bl&#x9;c03c6530 &lt;__asan_load4&gt;e5990010&#x9;ldr&#x9;r0, [r9, #16]e12fff30&#x9;blx&#x9;r0e356000f&#x9;cm&#x9;r6, #151a000014&#x9;bne&#x9;c06f1430 &lt;emulate_ldr+0xac&gt;e1a06000&#x9;mov&#x9;r6, r0e2840040&#x9;add&#x9;r0, r4, #64     ; 0x40......when running in emulate_ldr to simulate the ldr instruction, panicoccurred, and the log is as follows:Unable to handle kernel NULL pointer dereference at virtual address00000090pgd = ecb46400[00000090] *pgd=2e0fa003, *pmd=00000000Internal error: Oops: 206 [#1] SMP ARMPC is at cap_capable+0x14/0xb0LR is at emulate_ldr+0x50/0xc0psr: 600d0293 sp : ecd63af8  ip : 00000004  fp : c0a7c30cr10: 00000000  r9 : c30897f4  r8 : ecd63cd4r7 : 0000000f  r6 : 0000000a  r5 : e59fa090  r4 : ecd63c98r3 : c06ae294  r2 : 00000000  r1 : b7611300  r0 : bf4ec008Flags: nZCv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment userControl: 32c5387d  Table: 2d546400  DAC: 55555555Process 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-2021-47618)In the Linux kernel, the following vulnerability has been resolved:btrfs: fix use-after-free after failure to create a snapshotAt ioctl.c:create_snapshot(), we allocate a pending snapshot structure andthen attach it to the transaction&#39;s list of pending snapshots. After thatwe call btrfs_commit_transaction(), and if that returns an error we jumpto &#39;fail&#39; label, where we kfree() the pending snapshot structure. This canresult in a later use-after-free of the pending snapshot:1) We allocated the pending snapshot and added it to the transaction&#39;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&#39;t abort the transaction and we release our   transaction handle. We jump to the &#39;fail&#39; label and free the pending   snapshot structure. We return with the pending snapshot still in the   transaction&#39;s list;3) Another task commits the transaction. This time there&#39;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 thefollowing warning:  fs/btrfs/ioctl.c:843 create_snapshot() warn: &#39;&amp;pending_snapshot-&gt;list&#39; not removed from listSo fix this by not having the snapshot creation ioctl directly add thepending snapshot to the transaction&#39;s list. Instead add the pendingsnapshot to the transaction handle, and then at btrfs_commit_transaction()we add the snapshot to the list only when we can guarantee that any errorreturned after that point will result in a transaction abort, in whichcase the ioctl code can safely free the pending snapshot and no one canaccess it anymore.(CVE-2022-48733)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-timefield bounds checking for memcpy(), memmove(), and memset(), avoidintentionally writing across neighboring fields.Use flexible arrays instead of zero-element arrays (which look like theyare always overflowing) and split the cross-field memcpy() into two halvesthat can be appropriately bounds-checked by the compiler.We were doing:&#x9;#define ETH_HLEN  14&#x9;#define VLAN_HLEN  4&#x9;...&#x9;#define MLX5E_XDP_MIN_INLINE (ETH_HLEN + VLAN_HLEN)&#x9;...        struct mlx5e_tx_wqe      *wqe  = mlx5_wq_cyc_get_wqe(wq, pi);&#x9;...        struct mlx5_wqe_eth_seg  *eseg = &amp;wqe-&gt;eth;        struct mlx5_wqe_data_seg *dseg = wqe-&gt;data;&#x9;...&#x9;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 being2 bytes in size), but copying 18, intending to write across start(really vlan_tci, 2 bytes). The remaining 16 bytes get written intowqe-&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 buffersizes.&#34;pahole&#34; shows no size nor member offset changes to struct mlx5e_tx_wqenor struct mlx5e_umr_wqe. &#34;objdump -d&#34; shows no meaningful objectcode changes (i.e. only source line number induced differences andoptimizations).(CVE-2022-48744)In the Linux kernel, the following vulnerability has been resolved:KVM: LAPIC: Also cancel preemption timer during SET_LAPICThe 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:0x7fd39797350bThis can be triggered by not exposing tsc-deadline mode and doing a reboot inthe guest. The lapic_shutdown() function which is called in sys_reboot pathwill not disarm the flying timer, it just masks LVTT. lapic_shutdown() clearsAPIC state w/ LVT_MASKED and timer-mode bit is 0, this can trigger timer-modeswitch between tsc-deadline and oneshot/periodic, which can result in preemptiontimer be cancelled in apic_update_lvtt(). However, We can&#39;t depend on this whennot exposing tsc-deadline mode and oneshot/periodic modes emulated by preemptiontimer. Qemu will synchronise states around reset, let&#39;s cancel preemption timerunder KVM_SET_LAPIC.(CVE-2022-48765)In the Linux kernel, the following vulnerability has been resolved:media: lgdt3306a: Add a check against null-pointer-defThe 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-2022-48772)In the Linux kernel, the following vulnerability has been resolved:clk: mediatek: clk-mt6779: Add check for mtk_alloc_clk_dataAdd the check for the return value of mtk_alloc_clk_data() in order toavoid NULL pointer dereference.(CVE-2023-52873)In the Linux kernel, the following vulnerability has been resolved:of: dynamic: Synchronize of_changeset_destroy() with the devlink removalsIn 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 missingof_node_put():  ERROR: memory leak, expected refcount 1 instead of 2 ...Indeed, during the devlink removals performed at step 1, the removalitself releasing the device (and the attached of_node) is done by a jobqueued in a workqueue and so, it is done asynchronously with respect tofunction calls.When the warning is present, of_node_put() will be called but wronglytoo late from the workqueue job.In order to be sure that any ongoing devlink removals are done beforethe of_node destruction, synchronize the of_changeset_destroy() with thedevlink removals.(CVE-2024-35879)In the Linux kernel, the following vulnerability has been resolved:net/sched: act_skbmod: prevent kernel-infoleaksyzbot found that tcf_skbmod_dump() was copying four bytesfrom kernel stack to user space [1].The issue here is that &#39;struct tc_skbmod&#39; has a four bytes hole.We need to clear the structure before filling fields.[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]  simple_copy_to_iter net/core/datagram.c:532 [inline]  __skb_datagram_iter+0x185/0x1000 net/core/datagram.c:420  skb_copy_datagram_iter+0x5c/0x200 net/core/datagram.c:546  skb_copy_datagram_msg include/linux/skbuff.h:4050 [inline]  netlink_recvmsg+0x432/0x1610 net/netlink/af_netlink.c:1962  sock_recvmsg_nosec net/socket.c:1046 [inline]  sock_recvmsg+0x2c4/0x340 net/socket.c:1068  __sys_recvfrom+0x35a/0x5f0 net/socket.c:2242  __do_sys_recvfrom net/socket.c:2260 [inline]  __se_sys_recvfrom net/socket.c:2256 [inline]  __x64_sys_recvfrom+0x126/0x1d0 net/socket.c:2256 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at:  pskb_expand_head+0x30f/0x19d0 net/core/skbuff.c:2253  netlink_trim+0x2c2/0x330 net/netlink/af_netlink.c:1317  netlink_unicast+0x9f/0x1260 net/netlink/af_netlink.c:1351  nlmsg_unicast include/net/netlink.h:1144 [inline]  nlmsg_notify+0x21d/0x2f0 net/netlink/af_netlink.c:2610  rtnetlink_send+0x73/0x90 net/core/rtnetlink.c:741  rtnetlink_maybe_send include/linux/rtnetlink.h:17 [inline]  tcf_add_notify net/sched/act_api.c:2048 [inline]  tcf_action_add net/sched/act_api.c:2071 [inline]  tc_ctl_action+0x146e/0x19d0 net/sched/act_api.c:2119  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595  netlink_rcv_skb+0x375/0x650 net/netlink/af_netlink.c:2559  rtnetlink_rcv+0x34/0x40 net/core/rtnetlink.c:6613  netlink_unicast_kernel net/netlink/af_netlink.c:1335 [inline]  netlink_unicast+0xf4c/0x1260 net/netlink/af_netlink.c:1361  netlink_sendmsg+0x10df/0x11f0 net/netlink/af_netlink.c:1905  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 do_syscall_64+0xd5/0x1f0 entry_SYSCALL_64_after_hwframe+0x6d/0x75Uninit was stored to memory at:  __nla_put lib/nlattr.c:1041 [inline]  nla_put+0x1c6/0x230 lib/nlattr.c:1099  tcf_skbmod_dump+0x23f/0xc20 net/sched/act_skbmod.c:256  tcf_action_dump_old net/sched/act_api.c:1191 [inline]  tcf_action_dump_1+0x85e/0x970 net/sched/act_api.c:1227  tcf_action_dump+0x1fd/0x460 net/sched/act_api.c:1251  tca_get_fill+0x519/0x7a0 net/sched/act_api.c:1628  tcf_add_notify_msg net/sched/act_api.c:2023 [inline]  tcf_add_notify net/sched/act_api.c:2042 [inline]  tcf_action_add net/sched/act_api.c:2071 [inline]  tc_ctl_action+0x1365/0x19d0 net/sched/act_api.c:2119  rtnetlink_rcv_msg+0x1737/0x1900 net/core/rtnetlink.c:6595  netlink_rcv_skb+0x375/0x650 net/netlink/af_netli---truncated---(CVE-2024-35893)In the Linux kernel, the following vulnerability has been resolved:ipv6: fix race condition between ipv6_get_ifaddr and ipv6_del_addrAlthough ipv6_get_ifaddr walks inet6_addr_lst under the RCU lock, itstill means hlist_for_each_entry_rcu can return an item that got removedfrom the list. The memory itself of such item is not freed thanks to RCUbut nothing guarantees the actual content of the memory is sane.In particular, the reference count can be zero. This can happen ifipv6_del_addr is called in parallel. ipv6_del_addr removes the entryfrom inet6_addr_lst (hlist_del_init_rcu(&amp;ifp-&gt;addr_lst)) and drops allreferences (__in6_ifa_put(ifp) + in6_ifa_put(ifp)). With bad enoughtiming, 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 namein6_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-35969)In the Linux kernel, the following vulnerability has been resolved:riscv: Fix TASK_SIZE on 64-bit NOMMUOn NOMMU, userspace memory can come from anywhere in physical RAM. Thecurrent definition of TASK_SIZE is wrong if any RAM exists above 4G,causing spurious failures in the userspace access routines.(CVE-2024-35988)In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix oops during rmmod on single-CPU platformsDuring the removal of the idxd driver, registered offline callback isinvoked as part of the clean up process. However, on systems with onlyone CPU online, no valid target is available to migrate theperf 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 aninvalid target.(CVE-2024-35989)In the Linux kernel, the following vulnerability has been resolved:drm/arm/malidp: fix a possible null pointer dereferenceIn malidp_mw_connector_reset, new memory is allocated with kzalloc, butno 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-36014)In the Linux kernel, the following vulnerability has been resolved:tls: fix missing memory barrier in tls_initIn tls_init(), a write memory barrier is missing, and store-storereordering 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 observethe NULL value of ctx-&gt;sk_proto, causing NULL dereference.To fix it, we rely on rcu_assign_pointer() which implies the releasebarrier semantic. By moving rcu_assign_pointer() after ctx-&gt;sk_proto isinitialized, we can ensure that ctx-&gt;sk_proto are visible whenchanging sk-&gt;sk_prot.(CVE-2024-36489)In the Linux kernel, the following vulnerability has been resolved:virtio: delete vq in vp_find_vqs_msix() when request_irq() failsWhen request_irq() fails, error path calls vp_del_vqs(). There, as vq ispresent in the list, free_irq() is called for the same vector. Thatcauses 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-2024-37353)In the Linux kernel, the following vulnerability has been resolved:btrfs: fix crash on racing fsync and size-extending write into preallocWe have been seeing crashes on duplicate keys inbtrfs_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&#39;re logging a changed extent from fsync, which is splitting anextent 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 withdrgn (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][&#34;eb&#34;])  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 anditem 5 starts at i_size.Here is the state of ---truncated---(CVE-2024-37354)In the Linux kernel, the following vulnerability has been resolved:nfc: nci: Fix uninit-value in nci_rx_worksyzbot reported the following uninit-value access issue [1]nci_rx_work() parses received packet from ndev-&gt;rx_q. It should bevalidated header size, payload size and total packet size beforeprocessing the packet. If an invalid packet is detected, it should besilently discarded.(CVE-2024-38381)In the Linux kernel, the following vulnerability has been resolved:media: atomisp: ssh_css: Fix a null-pointer dereference in load_video_binariesThe allocation failure of mycs-&gt;yuv_scaler_binary in load_video_binaries()is followed with a dereference of mycs-&gt;yuv_scaler_binary after thefollowing 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 thesame memory slot as mycs-&gt;yuv_scaler_binary. Thus, a null-pointerdereference is triggered.(CVE-2024-38547)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix potential index out of bounds in color transformation functionFixes index out of bounds issue in the color transformation function.The issue could occur when the index &#39;i&#39; exceeds the number of transferfunction points (TRANSFER_FUNC_POINTS).The fix adds a check to ensure &#39;i&#39; is within bounds before accessing thetransfer function points. If &#39;i&#39; is out of bounds, an error message islogged 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 &#39;output_tf-&gt;tf_pts.red&#39; 1025 &lt;= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:406 cm_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.green&#39; 1025 &lt;= s32maxdrivers/gpu/drm/amd/amdgpu/../display/dc/dcn10/dcn10_cm_common.c:407 cm_helper_translate_curve_to_hw_format() error: buffer overflow &#39;output_tf-&gt;tf_pts.blue&#39; 1025 &lt;= s32max(CVE-2024-38552)In the Linux kernel, the following vulnerability has been resolved:net: fec: remove .ndo_poll_controller to avoid deadlocksThere is a deadlock issue found in sungem driver, please refer to thecommit ac0a230f719b (&#34;eth: sungem: remove .ndo_poll_controller to avoiddeadlocks&#34;). The root cause of the issue is that netpoll is in atomiccontext and disable_irq() is called by .ndo_poll_controller interfaceof sungem driver, however, disable_irq() might sleep. After analyzingthe implementation of fec_poll_controller(), the fec driver should havethe same issue. Due to the fec driver uses NAPI for TX completions, the.ndo_poll_controller is unnecessary to be implemented in the fec driver,so fec_poll_controller() can be safely removed.(CVE-2024-38553)In the Linux kernel, the following vulnerability has been resolved:ax25: Fix reference count leak issue of net_deviceThere is a reference count leak issue of the object &#34;net_device&#34; inax25_dev_device_down(). When the ax25 device is shutting down, theax25_dev_device_down() drops the reference count of net_device oneor zero times depending on if we goto unlock_put or not, which willcause memory leak.In order to solve the above issue, decrease the reference count ofnet_device after dev-&gt;ax25_ptr is set to null.(CVE-2024-38554)In the Linux kernel, the following vulnerability has been resolved:rcu-tasks: Fix show_rcu_tasks_trace_gp_kthread buffer overflowThere is a possibility of buffer overflow inshow_rcu_tasks_trace_gp_kthread() if counters, passedto sprintf() are huge. Counter numbers, needed for thisare unrealistically high, but buffer overflow is stillpossible.Use snprintf() with buffer size instead of sprintf().Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38577)In the Linux kernel, the following vulnerability has been resolved:crypto: bcm - Fix pointer arithmeticIn spu2_dump_omd() value of ptr is increased by ciph_key_leninstead of hash_iv_len which could lead to going beyond thebuffer boundaries.Fix this bug by changing ciph_key_len to hash_iv_len.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-38579)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() calledduring nilfs2 unmount.Analysis revealed that this is because nilfs_segctor_sync(), whichsynchronizes with the log writer thread, can be called afternilfs_segctor_destroy() terminates that thread, as shown in the call tracebelow: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 writerthread returns normally without synchronizing after it terminates, and byforcing tasks that are already waiting to complete once after the threadterminates.The skipped inode metadata flushout will then be processed together in thesubsequent cleanup work in nilfs_segctor_destroy().(CVE-2024-38582)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix use-after-free of timer for log writer threadPatch series &#34;nilfs2: fix log writer related issues&#34;.This bug fix series covers three nilfs2 log writer-related issues,including a timer use-after-free issue and potential deadlock issue onunmount, and a potential freeze issue in event synchronization foundduring 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 onthe nilfs_sc_info structure.The problem is that even though it is used to wake up a sleeping logwriter thread, sc_timer is not shut down until the nilfs_sc_info structureis about to be freed, and is used regardless of the thread&#39;s lifetime.Fix this issue by limiting the use of sc_timer only while the log writerthread is alive.(CVE-2024-38583)In the Linux kernel, the following vulnerability has been resolved:RDMA/hns: Modify the print level of CQE errorToo much print may lead to a panic in kernel. Change ibdev_err() toibdev_err_ratelimited(), and change the printing level of cqe dumpto debug level.(CVE-2024-38590)In the Linux kernel, the following vulnerability has been resolved:af_unix: Fix data races in unix_release_sock/unix_stream_sendmsgA data-race condition has been identified in af_unix. In one data path,the write function unix_release_sock() atomically writes tosk-&gt;sk_shutdown using WRITE_ONCE. However, on the reader side,unix_stream_sendmsg() does not read it atomically. Consequently, thisissue is causing the following KCSAN splat to occur:&#x9;BUG: KCSAN: data-race in unix_release_sock / unix_stream_sendmsg&#x9;write (marked) to 0xffff88867256ddbb of 1 bytes by task 7270 on cpu 28:&#x9;unix_release_sock (net/unix/af_unix.c:640)&#x9;unix_release (net/unix/af_unix.c:1050)&#x9;sock_close (net/socket.c:659 net/socket.c:1421)&#x9;__fput (fs/file_table.c:422)&#x9;__fput_sync (fs/file_table.c:508)&#x9;__se_sys_close (fs/open.c:1559 fs/open.c:1541)&#x9;__x64_sys_close (fs/open.c:1541)&#x9;x64_sys_call (arch/x86/entry/syscall_64.c:33)&#x9;do_syscall_64 (arch/x86/entry/common.c:?)&#x9;entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#x9;read to 0xffff88867256ddbb of 1 bytes by task 989 on cpu 14:&#x9;unix_stream_sendmsg (net/unix/af_unix.c:2273)&#x9;__sock_sendmsg (net/socket.c:730 net/socket.c:745)&#x9;____sys_sendmsg (net/socket.c:2584)&#x9;__sys_sendmmsg (net/socket.c:2638 net/socket.c:2724)&#x9;__x64_sys_sendmmsg (net/socket.c:2753 net/socket.c:2750 net/socket.c:2750)&#x9;x64_sys_call (arch/x86/entry/syscall_64.c:33)&#x9;do_syscall_64 (arch/x86/entry/common.c:?)&#x9;entry_SYSCALL_64_after_hwframe (arch/x86/entry/entry_64.S:130)&#x9;value changed: 0x01 -&gt; 0x03The line numbers are related to commit dd5a440a31fa (&#34;Linux 6.9-rc7&#34;).Commit e1d09c2c2f57 (&#34;af_unix: Fix data races around sk-&gt;sk_shutdown.&#34;)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 theother reads seem to be protected by unix_state_lock() as discussed in(CVE-2024-38596)In the Linux kernel, the following vulnerability has been resolved:ax25: Fix reference count leak issues of ax25_devThe ax25_addr_ax25dev() and ax25_dev_device_down() exist a referencecount leak issue of the object &#34;ax25_dev&#34;.Memory leak issue in ax25_addr_ax25dev():The reference count of the object &#34;ax25_dev&#34; can be increased multipletimes 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() andthen 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 isshutting down. The ax25_dev_device_down() drops the reference count onceor twice depending on if we goto unlock_put or not, which will causememory leak.As for the issue of ax25_addr_ax25dev(), it is impossible for one pointerto be on a list twice. So add a break in ax25_addr_ax25dev(). As for theissue of ax25_dev_device_down(), increase the reference count of ax25_devonce in ax25_dev_device_up() and decrease the reference count of ax25_devafter it is removed from the ax25_dev_list.(CVE-2024-38602)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 ensurethe irq vector can be destroyed when it fails.(CVE-2024-38603)In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Check &#39;folio&#39; pointer for NULLIt can be NULL if bmap is called.(CVE-2024-38625)In the Linux kernel, the following vulnerability has been resolved:serial: max3100: Update uart_driver_registered on driver removalThe removal of the last MAX3100 device triggers the removal ofthe driver. However, code doesn&#39;t update the respective globalvariable and after insmod — rmmod — insmod cycle the kerneloopses:  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/0xb0Update the actual state so next time UART driver will be registeredagain.Hugo also noticed, that the error path in the probe also affectedby having the variable set, and not cleared. Instead of clearing itmove the assignment after the successfull uart_register_driver() call.(CVE-2024-38633)In the Linux kernel, the following vulnerability has been resolved:greybus: lights: check return of get_channel_from_modeIf channel for the given node is not found we return null fromget_channel_from_mode. Make sure we validate the return pointerbefore 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-38637)In the Linux kernel, the following vulnerability has been resolved:dma-buf/sw-sync: don&#39;t enable IRQ from sync_print_obj()Since commit a6aa8fca4d79 (&#34;dma-buf/sw-sync: Reduce irqsave/irqrestore fromknown context&#34;) 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-38780)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/0x75Uninit 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/0x75If p9_check_errors() fails early in p9_client_rpc(), req-&gt;rc.tagwill 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 fieldssuch as &#39;tag&#39; and (just in case KMSAN unearths something new) &#39;id&#39;during the tag allocation stage.(CVE-2024-39301)Rejected reason: This CVE ID has been rejected or withdrawn by its CVE Numbering Authority.(CVE-2024-39362)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:600Read of size 1 at addr ffff88807a58c76c by task syz-executor280/5076CPU: 1 PID: 5076 Comm: syz-executor280 Not tainted 6.9.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call 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/0x7fThe root cause is we missed to do sanity check on i_xattr_nid duringf2fs_iget(), so that in fiemap() path, current_nat_addr() will accessnat_bitmap w/ offset from invalid i_xattr_nid, result in triggeringkasan bug report, fix it.(CVE-2024-39467)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.84.0.165.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.84.0.165.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1840</id>
          <title>An update for openvpn is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28882" id="CVE-2024-28882" title="CVE-2024-28882" type="cve"></reference>
          </references>
          <description>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-28882)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openvpn" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-2.5.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-debuginfo" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-debuginfo-2.5.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-debugsource" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-debugsource-2.5.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-devel" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-devel-2.5.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openvpn-help" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-help-2.5.5-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-2.5.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-debuginfo" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-debuginfo-2.5.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-debugsource" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-debugsource-2.5.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-devel" release="3.oe2203sp1" version="2.5.5">
                         <filename>openvpn-devel-2.5.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1842</id>
          <title>An update for cockpit is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6126" id="CVE-2024-6126" title="CVE-2024-6126" type="cve"></reference>
          </references>
          <description>A flaw was found in the cockpit package. This flaw allows an authenticated user to kill any process when enabling the pam_env&#39;s user_readenv option, which leads to a denial of service (DoS) attack.(CVE-2024-6126)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cockpit" release="17.oe2203sp1" version="178">
                         <filename>cockpit-178-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit-debuginfo" release="17.oe2203sp1" version="178">
                         <filename>cockpit-debuginfo-178-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit-debugsource" release="17.oe2203sp1" version="178">
                         <filename>cockpit-debugsource-178-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cockpit-devel" release="17.oe2203sp1" version="178">
                         <filename>cockpit-devel-178-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-cockpit-machines" release="17.oe2203sp1" version="178">
                         <filename>cockpit-cockpit-machines-178-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-cockpit-machines-ovirt" release="17.oe2203sp1" version="178">
                         <filename>cockpit-cockpit-machines-ovirt-178-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-help" release="17.oe2203sp1" version="178">
                         <filename>cockpit-help-178-17.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit" release="17.oe2203sp1" version="178">
                         <filename>cockpit-178-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-debuginfo" release="17.oe2203sp1" version="178">
                         <filename>cockpit-debuginfo-178-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-debugsource" release="17.oe2203sp1" version="178">
                         <filename>cockpit-debugsource-178-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cockpit-devel" release="17.oe2203sp1" version="178">
                         <filename>cockpit-devel-178-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1844</id>
          <title>An update for glibc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2961" id="CVE-2024-2961" title="CVE-2024-2961" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-2961)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="glibc-nss-devel" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-devel" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nscd" release="150.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="nss_modules" release="150.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-source" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debuginfo" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-common" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-all-langpacks" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-compat-2.17" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-locale-archive" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libnsl" release="150.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugsource" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="glibc-debugutils" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-150.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="glibc-help" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-help-2.34-150.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-all-langpacks" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-all-langpacks-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-archive" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-locale-archive-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-devel" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-devel-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugutils" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debugutils-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debuginfo" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debuginfo-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-common" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-common-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-compat-2.17" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-compat-2.17-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-debugsource" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-debugsource-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nscd" release="150.oe2203sp1" version="2.34">
                         <filename>nscd-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libnsl" release="150.oe2203sp1" version="2.34">
                         <filename>libnsl-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-locale-source" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-locale-source-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="glibc-nss-devel" release="150.oe2203sp1" version="2.34">
                         <filename>glibc-nss-devel-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="nss_modules" release="150.oe2203sp1" version="2.34">
                         <filename>nss_modules-2.34-150.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1846</id>
          <title>An update for openjpeg2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-39328" id="CVE-2023-39328" title="CVE-2023-39328" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-39328)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openjpeg2" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-2.5.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-debuginfo" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-debuginfo-2.5.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-debugsource" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-debugsource-2.5.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-devel" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-devel-2.5.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openjpeg2-tools" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-tools-2.5.0-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openjpeg2-help" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-help-2.5.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-2.5.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-debuginfo" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-debuginfo-2.5.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-debugsource" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-debugsource-2.5.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-devel" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-devel-2.5.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openjpeg2-tools" release="3.oe2203sp1" version="2.5.0">
                         <filename>openjpeg2-tools-2.5.0-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1849</id>
          <title>An update for arm-trusted-firmware is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6563" id="CVE-2024-6563" title="CVE-2024-6563" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6564" id="CVE-2024-6564" title="CVE-2024-6564" type="cve"></reference>
          </references>
          <description>Buffer Copy without Checking Size of Input (&#39;Classic Buffer Overflow&#39;) vulnerability in Renesas arm-trusted-firmware allows Local Execution of Code. This vulnerability is associated with program files  https://github.Com/renesas-rcar/arm-trusted-firmware/blob/rcar_gen3_v2.5/drivers/renesas/common/io/i... https://github.Com/renesas-rcar/arm-trusted-firmware/blob/rcar_gen3_v2.5/drivers/renesas/common/io/io_rcar.C .In line 313 &#34;addr_loaded_cnt&#34; is checked not to be &#34;CHECK_IMAGE_AREA_CNT&#34; (5) or larger, this check does not halt the function. Immediately after (line 317) there will be an overflow in the buffer and the value of &#34;dst&#34; will be written to the area immediately after the buffer, which is &#34;addr_loaded_cnt&#34;. This will allow an attacker to freely control the value of &#34;addr_loaded_cnt&#34; and thus control the destination of the write immediately after (line 318). The write in line 318 will then be fully controlled by said attacker, with whichever address and whichever value (&#34;len&#34;) they desire.(CVE-2024-6563)Buffer overflow in &#34;rcar_dev_init&#34;  due to using due to using untrusted data (rcar_image_number) as a loop counter before verifying it against RCAR_MAX_BL3X_IMAGE. This could lead to a full bypass of secure boot.(CVE-2024-6564)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="arm-trusted-firmware-armv8" release="5.oe2203sp1" version="2.3">
                         <filename>arm-trusted-firmware-armv8-2.3-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1856</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38474" id="CVE-2024-38474" title="CVE-2024-38474" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38477" id="CVE-2024-38477" title="CVE-2024-38477" type="cve"></reference>
          </references>
          <description>Substitution encoding issue in mod_rewrite in Apache HTTP Server 2.4.59 and earlier allows attacker to execute scripts indirectories 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 &#34;UnsafeAllow3F&#34; is specified.(CVE-2024-38474)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-38477)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="httpd" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-help-2.4.51-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1857</id>
          <title>An update for rapidjson is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38517" id="CVE-2024-38517" title="CVE-2024-38517" type="cve"></reference>
          </references>
          <description>Tencent RapidJSON is vulnerable to privilege escalation due to an integer underflow in the `GenericReader::ParseNumber()` function of `include/rapidjson/reader.h` when parsing JSON text from a stream. An attacker needs to send the victim a crafted file which needs to be opened; this triggers the integer underflow vulnerability (when the file is parsed), leading to elevation of privilege.(CVE-2024-38517)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rapidjson-devel" release="11.oe2203sp1" version="1.1.0">
                         <filename>rapidjson-devel-1.1.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rapidjson-help" release="11.oe2203sp1" version="1.1.0">
                         <filename>rapidjson-help-1.1.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1858</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4467" id="CVE-2024-4467" title="CVE-2024-4467" type="cve"></reference>
          </references>
          <description>A flaw was found in the QEMU disk image utility (qemu-img) &#39;info&#39; command. A specially crafted image file containing a `json:{}` value describing block devices in QMP could cause the qemu-img process on the host to consume large amounts of memory or CPU time, leading to denial of service or read/write to an existing external file.(CVE-2024-4467)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qemu" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-block-curl" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-block-iscsi" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-block-rbd" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-block-ssh" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-debuginfo" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-debugsource" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-guest-agent" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-hw-usb-host" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-img" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-system-aarch64" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-system-arm" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-system-riscv" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-system-x86_64" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-96.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qemu-help" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-96.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-block-curl" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-block-iscsi" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-block-rbd" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-block-ssh" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-debuginfo" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-debugsource" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-guest-agent" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-hw-usb-host" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-img" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-seabios" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-system-aarch64" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-system-arm" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-system-riscv" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-system-x86_64" release="96.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-96.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1860</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47391" id="CVE-2021-47391" title="CVE-2021-47391" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48721" id="CVE-2022-48721" title="CVE-2022-48721" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52743" id="CVE-2023-52743" title="CVE-2023-52743" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52755" id="CVE-2023-52755" title="CVE-2023-52755" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52833" id="CVE-2023-52833" title="CVE-2023-52833" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34027" id="CVE-2024-34027" title="CVE-2024-34027" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36478" id="CVE-2024-36478" title="CVE-2024-36478" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38540" id="CVE-2024-38540" title="CVE-2024-38540" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38558" id="CVE-2024-38558" title="CVE-2024-38558" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38570" id="CVE-2024-38570" title="CVE-2024-38570" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38586" id="CVE-2024-38586" title="CVE-2024-38586" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38598" id="CVE-2024-38598" title="CVE-2024-38598" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38605" id="CVE-2024-38605" title="CVE-2024-38605" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38615" id="CVE-2024-38615" title="CVE-2024-38615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38632" id="CVE-2024-38632" title="CVE-2024-38632" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39480" id="CVE-2024-39480" title="CVE-2024-39480" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39487" id="CVE-2024-39487" title="CVE-2024-39487" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39488" id="CVE-2024-39488" title="CVE-2024-39488" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39489" id="CVE-2024-39489" title="CVE-2024-39489" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39500" id="CVE-2024-39500" title="CVE-2024-39500" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40931" id="CVE-2024-40931" title="CVE-2024-40931" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40971" id="CVE-2024-40971" title="CVE-2024-40971" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:RDMA/cma: Ensure rdma_addr_cancel() happens before issuing more requestsThe FSM can run in a circle allowing rdma_resolve_ip() to be called twiceon the same id_priv. While this cannot happen without going through thework, it violates the invariant that the same address resolutionbackground request cannot be active twice.       CPU 1                                  CPU 2rdma_resolve_addr():  RDMA_CM_IDLE -&gt; RDMA_CM_ADDR_QUERY  rdma_resolve_ip(addr_handler)  #1&#x9;&#x9;&#x9; process_one_req(): for #1                          addr_handler():                            RDMA_CM_ADDR_QUERY -&gt; RDMA_CM_ADDR_BOUND                            mutex_unlock(&amp;id_priv-&gt;handler_mutex);                            [.. handler still running ..]rdma_resolve_addr():  RDMA_CM_ADDR_BOUND -&gt; RDMA_CM_ADDR_QUERY  rdma_resolve_ip(addr_handler)    !! two requests are now on the req_listrdma_destroy_id(): destroy_id_handler_unlock():  _destroy_id():   cma_cancel_operation():    rdma_addr_cancel()                          // process_one_req() self removes it&#x9;&#x9;          spin_lock_bh(&amp;lock);                           cancel_delayed_work(&amp;req-&gt;work);&#x9;                   if (!list_empty(&amp;req-&gt;list)) == true      ! rdma_addr_cancel() returns after process_on_req #1 is done   kfree(id_priv)&#x9;&#x9;&#x9; process_one_req(): for #2                          addr_handler():&#x9;                    mutex_lock(&amp;id_priv-&gt;handler_mutex);                            !! Use after free on id_privrdma_addr_cancel() expects there to be one req on the list and onlycancels the first one. The self-removal behavior of the work only happensafter the handler has returned. This yields a situations where thereq_list can have two reqs for the same &#34;handle&#34; but rdma_addr_cancel()only cancels the first one.The second req remains active beyond rdma_destroy_id() and willuse-after-free id_priv once it inevitably triggers.Fix this by remembering if the id_priv has called rdma_resolve_ip() andalways cancel before calling it again. This ensures the req_list nevergets more than one item in it and doesn&#39;t cost anything in the normal flowthat never uses this strange error path.(CVE-2021-47391)In the Linux kernel, the following vulnerability has been resolved:net/smc: Forward wakeup to smc socket waitqueue after fallbackWhen we replace TCP with SMC and a fallback occurs, there may besome socket waitqueue entries remaining in smc socket-&gt;wq, suchas eppoll_entries inserted by userspace applications.After the fallback, data flows over TCP/IP and only clcsocket-&gt;wqwill be woken up. Applications can&#39;t be notified by the entrieswhich were inserted in smc socket-&gt;wq before fallback. So we needa mechanism to wake up smc socket-&gt;wq at the same time if someentries remaining in it.The current workaround is to transfer the entries from smc socket-&gt;wqto clcsock-&gt;wq during the fallback. But this may cause a crashlike 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 fromsmc socket-&gt;wq to clcsock-&gt;wq. The owners of these entries, such asepoll, have no idea that the entries have been transferred to adifferent socket wait queue and still use original waitqueue spinlock(smc socket-&gt;wq.wait.lock) to make the entries operation exclusive,but it doesn&#39;t work. The operations to the entries, such as removingfrom the waitqueue (now is clcsock-&gt;wq after fallback), may cause acrash when clcsock waitqueue is being iterated over at the moment.This patch tries to fix this by no longer transferring wait queueentries privately, but introducing own implementations of clcsock&#39;scallback functions in fallback situation. The callback functions willforward the wakeup to smc socket-&gt;wq if clcsock-&gt;wq is actually wokenup and smc socket-&gt;wq has remaining entries.(CVE-2022-48721)In the Linux kernel, the following vulnerability has been resolved:ice: Do not use WQ_MEM_RECLAIM flag for workqueueWhen both ice and the irdma driver are loaded, a warning incheck_flush_dependency is being triggered. This is due to ice driverworkqueue being allocated with the WQ_MEM_RECLAIM flag and the irdma oneis not.According to kernel documentation, this flag should be set if theworkqueue will be involved in the kernel&#39;s memory reclamation flow.Since it is not, there is no need for the ice driver&#39;s WQ to have thisflag 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_chain_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 crct10dif_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_uverbsib_core intel_uncore joydev pcspkr i2c_i801 acpi_ipmi mei lpc_ich i2c_smbus intel_pch_thermal ioatdma ipmi_si acpi_power_meteracpi_pad xfs libcrc32c sd_mod t10_pi crc64_rocksoft crc64 sg ahci ixgbe libahci ice i40e igb crc32c_intel mdio i2c_algo_bit libata 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 089f 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-2023-52743)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 pntsdallocation size. This patch add the check to validate 3 offsets usingallocation size.(CVE-2023-52755)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: btusb: Add date-&gt;evt_skb is NULL checkfix 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-2023-52833)In the Linux kernel, the following vulnerability has been resolved:f2fs: compress: fix to cover {reserve,release}_compress_blocks() w/ cp_rwsem lockIt needs to cover {reserve,release}_compress_blocks() w/ cp_rwsem lockto avoid racing with checkpoint, otherwise, filesystem metadata includingblkaddr in dnode, inode fields and .total_valid_block_count may becorrupted after SPO case.(CVE-2024-34027)In the Linux kernel, the following vulnerability has been resolved:null_blk: fix null-ptr-dereference while configuring &#39;power&#39; and &#39;submit_queues&#39;Writing &#39;power&#39; and &#39;submit_queues&#39; concurrently will trigger kernelpanic:Test script:modprobe null_blk nr_devices=0mkdir -p /sys/kernel/config/nullb/nullb0while 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; doneTest result:BUG: kernel NULL pointer dereference, address: 0000000000000148Oops: 0000 [#1] PREEMPT SMPRIP: 0010:__lock_acquire+0x41d/0x28f0Call 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/0x150This is because del_gendisk() can concurrent withblk_mq_update_nr_hw_queues():nullb_device_power_store&#x9;nullb_apply_submit_queues null_del_dev del_gendisk&#x9;&#x9;&#x9;&#x9; nullb_update_nr_hw_queues&#x9;&#x9;&#x9;&#x9;  if (!dev-&gt;nullb)&#x9;&#x9;&#x9;&#x9;  // still set while gendisk is deleted&#x9;&#x9;&#x9;&#x9;   return 0&#x9;&#x9;&#x9;&#x9;  blk_mq_update_nr_hw_queues dev-&gt;nullb = NULLFix this problem by resuing the global mutex to protectnullb_device_power_store() and nullb_update_nr_hw_queues() from configfs.(CVE-2024-36478)In the Linux kernel, the following vulnerability has been resolved:bnxt_re: avoid shift undefined behavior in bnxt_qplib_alloc_init_hwqUndefined behavior is triggered when bnxt_qplib_alloc_init_hwq is calledwith hwq_attr-&gt;aux_depth != 0 and hwq_attr-&gt;aux_stride == 0.In that case, &#34;roundup_pow_of_two(hwq_attr-&gt;aux_stride)&#34; 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 &#39;long unsigned int&#39;  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-38540)In the Linux kernel, the following vulnerability has been resolved:net: openvswitch: fix overwriting ct original tuple for ICMPv6OVS_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 structurewith the metadata like conntrack state, input port, recirculation id,etc.  Then the packet itself gets parsed to populate the rest of thekeys from the packet headers.Whenever the packet parsing code starts parsing the ICMPv6 header, itfirst zeroes out fields in the key corresponding to Neighbor Discoveryinformation even if it is not an ND packet.It is an &#39;ipv6.nd&#39; field.  However, the &#39;ipv6&#39; is a union that sharesthe space between &#39;nd&#39; and &#39;ct_orig&#39; that holds the original tupleconntrack metadata parsed from the OVS_PACKET_ATTR_KEY.ND packets should not normally have conntrack state, so it&#39;s fine toshare the space, but normal ICMPv6 Echo packets or maybe other types ofICMPv6 can have the state attached and it should not be overwritten.The issue results in all but the last 4 bytes of the destinationaddress being wiped from the original conntrack tuple leading toincorrect packet matching and potentially executing wrong actionsin case this packet recirculates within the datapath or goes backto userspace.ND fields should not be accessed in non-ND packets, so not clearingthem should be fine.  Executing memset() only for actual ND packets toavoid the issue.Initializing the whole thing before parsing is needed because ND packetmay not contain all the options.The issue only affects the OVS_PACKET_CMD_EXECUTE path and doesn&#39;taffect packets entering OVS datapath from network interfaces, becausein this case CT metadata is populated from skb after the packet isalready parsed.(CVE-2024-38558)In the Linux kernel, the following vulnerability has been resolved:gfs2: Fix potential glock use-after-free on unmountWhen a DLM lockspace is released and there ares still locks in thatlockspace, DLM will unlock those locks automatically.  Commitfb6791d100d1b started exploiting this behavior to speed up filesystemunmount: gfs2 would simply free glocks it didn&#39;t want to unlock and thenrelease the lockspace.  This didn&#39;t take the bast callbacks forasynchronous lock contention notifications into account, which remainactive until until a lock is unlocked or its lockspace is released.To prevent those callbacks from accessing deallocated objects, put theglocks that should not be unlocked on the sd_dead_glocks list, releasethe lockspace, and only then free those glocks.As an additional measure, ignore unexpected ast and bast callbacks ifthe receiving glock is dead.(CVE-2024-38570)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 fragmentedpackets, whereby invalid entries were inserted into the transmit ringbuffer, subsequently leading to calls to dma_unmap_single() with a nulladdress.This was caused by rtl8169_start_xmit() not noticing changes to nr_fragswhich may occur when small packets are padded (to work around hardwarequirks) in rtl8169_tso_csum_v2().To fix this, postpone inspecting nr_frags until after any padding has beenapplied.(CVE-2024-38586)In the Linux kernel, the following vulnerability has been resolved:md: fix resync softlockup when bitmap size is less than array sizeIs is reported that for dm-raid10, lvextend + lvchange --syncaction willtrigger 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 #1RIP: 0010:_raw_spin_unlock_irq+0x13/0x30Call 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/0x30And 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 changeRoot cause is that commit 301867b1c168 (&#34;md/raid10: checkslab-out-of-bounds in md_bitmap_get_counter&#34;) return early frommd_bitmap_get_counter(), without setting returned blocks.Fix this problem by always set returned blocks frommd_bitmap_get_counter&#34;(), as it used to be.Noted that this patch just fix the softlockup problem in kernel, thecase that bitmap size doesn&#39;t match array size still need to be fixed.(CVE-2024-38598)In the Linux kernel, the following vulnerability has been resolved:ALSA: core: Fix NULL module pointer assignment at card initThe commit 81033c6b584b (&#34;ALSA: core: Warn on empty module&#34;)introduced a WARN_ON() for a NULL module pointer passed at snd_cardobject creation, and it also wraps the code around it with &#39;#ifdefMODULE&#39;.  This works in most cases, but the devils are always indetails.  &#34;MODULE&#34; is defined when the target code (i.e. the soundcore) is built as a module; but this doesn&#39;t mean that the caller isalso 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&#39;s non-NULL, andcard-&gt;module remains as NULL.  This would result in the missing modulereference up/down at the device open/close, leading to a race with thecode execution after the module removal.For addressing the bug, move the assignment of card-&gt;module again outof ifdef.  The WARN_ON() is still wrapped with ifdef because themodule can be really NULL when all sound drivers are built-in.Note that we keep &#39;ifdef MODULE&#39; for WARN_ON(), otherwise it wouldlead to a false-positive NULL module check.  Admittedly it won&#39;t catchperfectly, i.e. no check is performed when CONFIG_SND=y.  But, it&#39;s noreal problem as it&#39;s only for debugging, and the condition is prettyrare.(CVE-2024-38605)In the Linux kernel, the following vulnerability has been resolved:cpufreq: exit() callback is optionalThe exit() callback is optional and shouldn&#39;t be called without checkinga valid pointer first.Also, we must clear freq_table pointer even if the exit() callback isn&#39;tpresent.(CVE-2024-38615)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 &#39;name&#39; memory leak.(CVE-2024-38632)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-39480)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 anempty string, newval-&gt;string+1 will point to the byte after thestring, causing an out-of-bound read.BUG: KASAN: slab-out-of-bounds in strlen+0x7d/0xa0 lib/string.c:418Read of size 1 at addr ffff8881119c4781 by task syz-executor665/8107CPU: 1 PID: 8107 Comm: syz-executor665 Not tainted 6.7.0-rc7 #1Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014Call 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/0x910drivers/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-39487)In the Linux kernel, the following vulnerability has been resolved:arm64: asm-bug: Add .align 2 to the end of __BUG_ENTRYWhen CONFIG_DEBUG_BUGVERBOSE=n, we fail to add necessary padding bytesto bug_table entries, and as a result the last entry in a bug table willbe ignored, potentially leading to an unexpected panic(). All priorentries in the table will be handled correctly.The arm64 ABI requires that struct fields of up to 8 bytes arenaturally-aligned, with padding added within a struct such that structare suitably aligned within arrays.When CONFIG_DEBUG_BUGVERPOSE=y, the layout of a bug_entry is:&#x9;struct bug_entry {&#x9;&#x9;signed int      bug_addr_disp;&#x9;// 4 bytes&#x9;&#x9;signed int      file_disp;&#x9;// 4 bytes&#x9;&#x9;unsigned short  line;&#x9;&#x9;// 2 bytes&#x9;&#x9;unsigned short  flags;&#x9;&#x9;// 2 bytes&#x9;}... with 12 bytes total, requiring 4-byte alignment.When CONFIG_DEBUG_BUGVERBOSE=n, the layout of a bug_entry is:&#x9;struct bug_entry {&#x9;&#x9;signed int      bug_addr_disp;&#x9;// 4 bytes&#x9;&#x9;unsigned short  flags;&#x9;&#x9;// 2 bytes&#x9;&#x9;&lt; implicit padding &gt;&#x9;&#x9;// 2 bytes&#x9;}... with 8 bytes total, with 6 bytes of data and 2 bytes of trailingpadding, requiring 4-byte alginment.When we create a bug_entry in assembly, we align the start of the entryto 4 bytes, which implicitly handles padding for any prior entries.However, we do not align the end of the entry, and so whenCONFIG_DEBUG_BUGVERBOSE=n, the final entry lacks the trailing paddingbytes.For the main kernel image this is not a problem as find_bug() doesn&#39;tdepend on the trailing padding bytes when searching for entries:&#x9;for (bug = __start___bug_table; bug &lt; __stop___bug_table; ++bug)&#x9;&#x9;if (bugaddr == bug_addr(bug))&#x9;&#x9;&#x9;return bug;However for modules, module_bug_finalize() depends on the trailingbytes when calculating the number of entries:&#x9;mod-&gt;num_bugs = sechdrs[i].sh_size / sizeof(struct bug_entry);... and as the last bug_entry lacks the necessary padding bytes, this entrywill not be counted, e.g. in the case of a single entry:&#x9;sechdrs[i].sh_size == 6&#x9;sizeof(struct bug_entry) == 8;&#x9;sechdrs[i].sh_size / sizeof(struct bug_entry) == 0;Consequently module_find_bug() will miss the last bug_entry when it does:&#x9;for (i = 0; i &lt; mod-&gt;num_bugs; ++i, ++bug)&#x9;&#x9;if (bugaddr == bug_addr(bug))&#x9;&#x9;&#x9;goto out;... which can lead to a kenrel panic due to an unhandled bug.This can be demonstrated with the following module:&#x9;static int __init buginit(void)&#x9;{&#x9;&#x9;WARN(1, &#34;hello\n&#34;);&#x9;&#x9;return 0;&#x9;}&#x9;static void __exit bugexit(void)&#x9;{&#x9;}&#x9;module_init(buginit);&#x9;module_exit(bugexit);&#x9;MODULE_LICENSE(&#34;GPL&#34;);... which will trigger a kernel panic when loaded:&#x9;------------[ cut here ]------------&#x9;hello&#x9;Unexpected kernel BRK exception at EL1&#x9;Internal error: BRK handler: 00000000f2000800 [#1] PREEMPT SMP&#x9;Modules linked in: hello(O+)&#x9;CPU: 0 PID: 50 Comm: insmod Tainted: G           O       6.9.1 #8&#x9;Hardware name: linux,dummy-virt (DT)&#x9;pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)&#x9;pc : buginit+0x18/0x1000 [hello]&#x9;lr : buginit+0x18/0x1000 [hello]&#x9;sp : ffff800080533ae0&#x9;x29: ffff800080533ae0 x28: 0000000000000000 x27: 0000000000000000&#x9;x26: ffffaba8c4e70510 x25: ffff800080533c30 x24: ffffaba8c4a28a58&#x9;x23: 0000000000000000 x22: 0000000000000000 x21: ffff3947c0eab3c0&#x9;x20: ffffaba8c4e3f000 x19: ffffaba846464000 x18: 0000000000000006&#x9;x17: 0000000000000000 x16: ffffaba8c2492834 x15: 0720072007200720&#x9;x14: 0720072007200720 x13: ffffaba8c49b27c8 x12: 0000000000000312&#x9;x11: 0000000000000106 x10: ffffaba8c4a0a7c8 x9 : ffffaba8c49b27c8&#x9;x8 : 00000000ffffefff x7 : ffffaba8c4a0a7c8 x6 : 80000000fffff000&#x9;x5 : 0000000000000107 x4 : 0000000000000000 x3 : 0000000000000000&#x9;x2 : 0000000000000000 x1 : 0000000000000000 x0 : ffff3947c0eab3c0&#x9;Call trace:&#x9; buginit+0x18/0x1000 [hello]&#x9; do_one_initcall+0x80/0x1c8&#x9; do_init_module+0x60/0x218&#x9; load_module+0x1ba4/0x1d70&#x9; __do_sys_init_module+0x198/0x1d0&#x9; __arm64_sys_init_module+0x1c/0x28&#x9; invoke_syscall+0x48/0x114&#x9; el0_svc---truncated---(CVE-2024-39488)In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix memleak in seg6_hmac_init_algoseg6_hmac_init_algo returns without cleaning up the previous allocationsif one fails, so it&#39;s going to leak all that memory and the crypto tfms.Update seg6_hmac_exit to only free the memory when allocated, so we canreuse the code directly.(CVE-2024-39489)In the Linux kernel, the following vulnerability has been resolved:sock_map: avoid race between sock_map_close and sk_psock_putsk_psock_get will return NULL if the refcount of psock has gone to 0, whichwill 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 stillpoint 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:1701Modules linked in:CPU: 1 PID: 7220 Comm: syz-executor380 Not tainted 6.9.0-syzkaller-07726-g3c999d1ae3c7 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024RIP: 0010:sock_map_close+0x2a2/0x2d0 net/core/sock_map.c:1701Code: 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 02RSP: 0018:ffffc9000441fda8 EFLAGS: 00010293RAX: ffffffff89731ae1 RBX: ffffffff94b87540 RCX: ffff888029470000RDX: 0000000000000000 RSI: ffffffff8bcab5c0 RDI: ffffffff8c1faba0RBP: 0000000000000000 R08: ffffffff92f9b61f R09: 1ffffffff25f36c3R10: dffffc0000000000 R11: fffffbfff25f36c4 R12: ffffffff89731840R13: ffff88804b587000 R14: ffff88804b587000 R15: ffffffff89731870FS:  000055555e080380(0000) GS:ffff8880b9500000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000207d4000 CR4: 0000000000350ef0Call 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/0x7fRIP: 0033:0x7fb37d618070Code: 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 7cRSP: 002b:00007ffcd4a525d8 EFLAGS: 00000202 ORIG_RAX: 0000000000000003RAX: ffffffffffffffda RBX: 0000000000000005 RCX: 00007fb37d618070RDX: 0000000000000010 RSI: 00000000200001c0 RDI: 0000000000000004RBP: 0000000000000000 R08: 0000000100000000 R09: 0000000100000000R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 &lt;/TASK&gt;Use sk_psock, which will only check that the pointer is not been set toNULL 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 cancelpsock-&gt;work.As suggested by Paolo Abeni, reorder the condition so the control flow isless convoluted.After that change, the reproducer does not trigger the WARN_ON_ONCEanymore.(CVE-2024-39500)In the Linux kernel, the following vulnerability has been resolved:mptcp: ensure snd_una is properly initialized on connectThis is strictly related to commit fb7a0d334894 (&#34;mptcp: ensure snd_nxtis properly initialized on connect&#34;). It turns out that syzkaller cantrigger the retransmit after fallback and before processing any otherincoming packet - so that snd_una is still left uninitialized.Address the issue explicitly initializing snd_una together with snd_nxtand write_seq.(CVE-2024-40931)In the Linux kernel, the following vulnerability has been resolved:f2fs: remove clear SB_INLINECRYPT flag in default_optionsIn f2fs_remount, SB_INLINECRYPT flag will be clear and re-set.If create new file or open file during this gap, these fileswill not use inlinecrypt. Worse case, it may lead to datacorruption if wrappedkey_v0 is enable.Thread A:                               Thread B:-f2fs_remount&#x9;&#x9;&#x9;&#x9;-f2fs_file_open or f2fs_new_inode  -default_options&#x9;&lt;- clear SB_INLINECRYPT flag                                          -fscrypt_select_encryption_impl  -parse_options&#x9;&lt;- set SB_INLINECRYPT again(CVE-2024-40971)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.85.0.166.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.85.0.166.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1867</id>
          <title>An update for python-pip is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-43804" id="CVE-2023-43804" title="CVE-2023-43804" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45803" id="CVE-2023-45803" title="CVE-2023-45803" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37891" id="CVE-2024-37891" title="CVE-2024-37891" type="cve"></reference>
          </references>
          <description>urllib3 is a user-friendly HTTP client library for Python. urllib3 doesn&#39;t treat the `Cookie` HTTP header special or provide any helpers for managing cookies over HTTP, that is the responsibility of the user. However, it is possible for a user to specify a `Cookie` header and unknowingly leak information via HTTP redirects to a different origin if that user doesn&#39;t disable redirects explicitly. This issue has been patched in urllib3 version 1.26.17 or 2.0.5.(CVE-2023-43804)urllib3 is a user-friendly HTTP client library for Python. urllib3 previously wouldn&#39;t remove the HTTP request body when an HTTP redirect response using status 301, 302, or 303 after the request had its method changed from one that could accept a request body (like `POST`) to `GET` as is required by HTTP RFCs. Although this behavior is not specified in the section for redirects, it can be inferred by piecing together information from different sections and we have observed the behavior in other major HTTP client implementations like curl and web browsers. Because the vulnerability requires a previously trusted service to become compromised in order to have an impact on confidentiality we believe the exploitability of this vulnerability is low. Additionally, many users aren&#39;t putting sensitive data in HTTP request bodies, if this is the case then this vulnerability isn&#39;t exploitable. Both of the following conditions must be true to be affected by this vulnerability: 1. Using urllib3 and submitting sensitive information in the HTTP request body (such as form data or JSON) and 2. The origin service is compromised and starts redirecting using 301, 302, or 303 to a malicious peer or the redirected-to service becomes compromised. This issue has been addressed in versions 1.26.18 and 2.0.7 and users are advised to update to resolve this issue. Users unable to update should disable redirects for services that aren&#39;t expecting to respond with redirects with `redirects=False` and disable automatic redirects with `redirects=False` and handle 301, 302, and 303 redirects manually by stripping the HTTP request body.(CVE-2023-45803) urllib3 is a user-friendly HTTP client library for Python. When using urllib3&#39;s proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3&#39;s proxy support, it&#39;s possible to accidentally configure the `Proxy-Authorization` header even though it won&#39;t have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn&#39;t treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn&#39;t strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3&#39;s proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren&#39;t using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3&#39;s built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3&#39;s `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.(CVE-2024-37891)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-pip-help" release="6.oe2203sp1" version="21.3.1">
                         <filename>python-pip-help-21.3.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-pip-wheel" release="6.oe2203sp1" version="21.3.1">
                         <filename>python-pip-wheel-21.3.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-pip" release="6.oe2203sp1" version="21.3.1">
                         <filename>python3-pip-21.3.1-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1870</id>
          <title>An update for openssh is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6409" id="CVE-2024-6409" title="CVE-2024-6409" type="cve"></reference>
          </references>
          <description>A race condition vulnerability was discovered in how signals are handled by OpenSSH&#39;s server (sshd). If a remote attacker does not authenticate within a set time period, then sshd&#39;s SIGALRM handler is called asynchronously. However, this signal handler calls various functions that are not async-signal-safe, for example, syslog(). As a consequence of a successful attack, in the worst case scenario, an attacker may be able to perform a remote code execution (RCE) as an unprivileged user running the sshd server.(CVE-2024-6409)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openssh" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-askpass" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-clients" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debuginfo" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-debugsource" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-keycat" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssh-server" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="pam_ssh_agent_auth" release="4.32.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssh-help" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-help-8.8p1-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-8.8p1-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-askpass" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-askpass-8.8p1-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-clients" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-clients-8.8p1-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debuginfo" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-debuginfo-8.8p1-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-debugsource" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-debugsource-8.8p1-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-keycat" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-keycat-8.8p1-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssh-server" release="32.oe2203sp1" version="8.8p1">
                         <filename>openssh-server-8.8p1-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="pam_ssh_agent_auth" release="4.32.oe2203sp1" version="0.10.4">
                         <filename>pam_ssh_agent_auth-0.10.4-4.32.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1876</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1475" id="CVE-2022-1475" title="CVE-2022-1475" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48434" id="CVE-2022-48434" title="CVE-2022-48434" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-32230" id="CVE-2024-32230" title="CVE-2024-32230" type="cve"></reference>
          </references>
          <description>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-1475)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-2022-48434)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-2024-32230)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="17.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-17.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="17.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="17.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-17.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1878</id>
          <title>An update for freeradius is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3596" id="CVE-2024-3596" title="CVE-2024-3596" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-3596)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="freeradius" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-debuginfo" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-debuginfo-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-debugsource" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-debugsource-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-devel" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-devel-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-help" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-help-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-krb5" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-krb5-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-ldap" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-ldap-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-mysql" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-mysql-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-perl" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-perl-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-postgresql" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-postgresql-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-sqlite" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-sqlite-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="freeradius-utils" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-utils-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-freeradius" release="3.oe2203sp1" version="3.0.25">
                         <filename>python3-freeradius-3.0.25-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-debuginfo" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-debuginfo-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-debugsource" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-debugsource-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-devel" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-devel-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-help" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-help-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-krb5" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-krb5-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-ldap" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-ldap-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-mysql" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-mysql-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-perl" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-perl-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-postgresql" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-postgresql-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-sqlite" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-sqlite-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="freeradius-utils" release="3.oe2203sp1" version="3.0.25">
                         <filename>freeradius-utils-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-freeradius" release="3.oe2203sp1" version="3.0.25">
                         <filename>python3-freeradius-3.0.25-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1879</id>
          <title>An update for openssl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5535" id="CVE-2024-5535" title="CVE-2024-5535" type="cve"></reference>
          </references>
          <description>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 &#34;no overlap&#34;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.(CVE-2024-5535)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openssl" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssl-debuginfo" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssl-debugsource" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssl-devel" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssl-libs" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openssl-perl" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-37.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openssl-help" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-help-1.1.1m-37.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssl" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-1.1.1m-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssl-debuginfo" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debuginfo-1.1.1m-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssl-debugsource" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-debugsource-1.1.1m-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssl-devel" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-devel-1.1.1m-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssl-libs" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-libs-1.1.1m-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openssl-perl" release="37.oe2203sp1" version="1.1.1m">
                         <filename>openssl-perl-1.1.1m-37.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1880</id>
          <title>An update for mongo-c-driver is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-19"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6383" id="CVE-2024-6383" title="CVE-2024-6383" type="cve"></reference>
          </references>
          <description>The bson_string_append function in MongoDB C Driver may be vulnerable to a buffer overflow where the function might attempt to allocate too small of buffer and may lead to memory corruption of neighbouring heap memory. This issue affects libbson versions prior to 1.27.1(CVE-2024-6383)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libbson" release="1.oe2203sp1" version="1.27.4">
                         <filename>libbson-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libbson-devel" release="1.oe2203sp1" version="1.27.4">
                         <filename>libbson-devel-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debuginfo" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-debuginfo-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debugsource" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-debugsource-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-devel" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-devel-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-help" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-help-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson" release="1.oe2203sp1" version="1.27.4">
                         <filename>libbson-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson-devel" release="1.oe2203sp1" version="1.27.4">
                         <filename>libbson-devel-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debuginfo" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-debuginfo-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debugsource" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-debugsource-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-devel" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-devel-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-help" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-help-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1882</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21129" id="CVE-2024-21129" title="CVE-2024-21129" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21163" id="CVE-2024-21163" title="CVE-2024-21163" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21171" id="CVE-2024-21171" title="CVE-2024-21171" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21173" id="CVE-2024-21173" title="CVE-2024-21173" type="cve"></reference>
          </references>
          <description>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-21129)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).(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 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-21171)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-21173)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1885</id>
          <title>An update for openvpn is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5594" id="CVE-2024-5594" title="CVE-2024-5594" type="cve"></reference>
          </references>
          <description>(CVE-2024-5594)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="openvpn" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-2.5.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-debuginfo" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-debuginfo-2.5.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-debugsource" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-debugsource-2.5.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="openvpn-devel" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-devel-2.5.5-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="openvpn-help" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-help-2.5.5-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-2.5.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-debuginfo" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-debuginfo-2.5.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-debugsource" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-debugsource-2.5.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="openvpn-devel" release="4.oe2203sp1" version="2.5.5">
                         <filename>openvpn-devel-2.5.5-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1886</id>
          <title>An update for gtk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6655" id="CVE-2024-6655" title="CVE-2024-6655" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-6655)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gtk2" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-2.24.33-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-debuginfo" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-debuginfo-2.24.33-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-debugsource" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-debugsource-2.24.33-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-devel" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-devel-2.24.33-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-help" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-help-2.24.33-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk2-immodule-xim" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-immodule-xim-2.24.33-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-2.24.33-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-debuginfo" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-debuginfo-2.24.33-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-debugsource" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-debugsource-2.24.33-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-devel" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-devel-2.24.33-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-help" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-help-2.24.33-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk2-immodule-xim" release="9.oe2203sp1" version="2.24.33">
                         <filename>gtk2-immodule-xim-2.24.33-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1890</id>
          <title>An update for python-zipp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5569" id="CVE-2024-5569" title="CVE-2024-5569" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-5569)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-zipp-help" release="3.oe2203sp1" version="3.7.0">
                         <filename>python-zipp-help-3.7.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-zipp" release="3.oe2203sp1" version="3.7.0">
                         <filename>python3-zipp-3.7.0-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1891</id>
          <title>An update for mongo-c-driver is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6381" id="CVE-2024-6381" title="CVE-2024-6381" type="cve"></reference>
          </references>
          <description>The bson_strfreev function in the MongoDB C driver library may be susceptible to an integer overflow where the function will try to free memory at a negative offset. This may result in memory corruption. This issue affected libbson versions prior to 1.26.2(CVE-2024-6381)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libbson" release="1.oe2203sp1" version="1.27.4">
                         <filename>libbson-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libbson-devel" release="1.oe2203sp1" version="1.27.4">
                         <filename>libbson-devel-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debuginfo" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-debuginfo-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-debugsource" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-debugsource-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-devel" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-devel-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mongo-c-driver-help" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-help-1.27.4-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson" release="1.oe2203sp1" version="1.27.4">
                         <filename>libbson-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libbson-devel" release="1.oe2203sp1" version="1.27.4">
                         <filename>libbson-devel-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debuginfo" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-debuginfo-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-debugsource" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-debugsource-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-devel" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-devel-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mongo-c-driver-help" release="1.oe2203sp1" version="1.27.4">
                         <filename>mongo-c-driver-help-1.27.4-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1892</id>
          <title>An update for gtk3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6655" id="CVE-2024-6655" title="CVE-2024-6655" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-6655)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gtk-update-icon-cache" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk-update-icon-cache-3.24.30-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-3.24.30-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-debuginfo" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-debuginfo-3.24.30-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-debugsource" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-debugsource-3.24.30-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-devel" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-devel-3.24.30-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-help" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-help-3.24.30-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gtk3-immodule-xim" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-immodule-xim-3.24.30-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk-update-icon-cache" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk-update-icon-cache-3.24.30-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-3.24.30-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-debuginfo" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-debuginfo-3.24.30-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-debugsource" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-debugsource-3.24.30-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-devel" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-devel-3.24.30-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-help" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-help-3.24.30-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gtk3-immodule-xim" release="11.oe2203sp1" version="3.24.30">
                         <filename>gtk3-immodule-xim-3.24.30-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1896</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47432" id="CVE-2021-47432" title="CVE-2021-47432" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47622" id="CVE-2021-47622" title="CVE-2021-47622" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48814" id="CVE-2022-48814" title="CVE-2022-48814" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48816" id="CVE-2022-48816" title="CVE-2022-48816" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48844" id="CVE-2022-48844" title="CVE-2022-48844" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52757" id="CVE-2023-52757" title="CVE-2023-52757" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52781" id="CVE-2023-52781" title="CVE-2023-52781" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36939" id="CVE-2024-36939" title="CVE-2024-36939" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38559" id="CVE-2024-38559" title="CVE-2024-38559" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38568" id="CVE-2024-38568" title="CVE-2024-38568" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38578" id="CVE-2024-38578" title="CVE-2024-38578" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38589" id="CVE-2024-38589" title="CVE-2024-38589" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38618" id="CVE-2024-38618" title="CVE-2024-38618" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38619" id="CVE-2024-38619" title="CVE-2024-38619" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39469" id="CVE-2024-39469" title="CVE-2024-39469" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39472" id="CVE-2024-39472" title="CVE-2024-39472" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39494" id="CVE-2024-39494" title="CVE-2024-39494" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39499" id="CVE-2024-39499" title="CVE-2024-39499" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39505" id="CVE-2024-39505" title="CVE-2024-39505" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40904" id="CVE-2024-40904" title="CVE-2024-40904" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40905" id="CVE-2024-40905" title="CVE-2024-40905" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40912" id="CVE-2024-40912" title="CVE-2024-40912" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40929" id="CVE-2024-40929" title="CVE-2024-40929" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40932" id="CVE-2024-40932" title="CVE-2024-40932" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40941" id="CVE-2024-40941" title="CVE-2024-40941" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40943" id="CVE-2024-40943" title="CVE-2024-40943" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40968" id="CVE-2024-40968" title="CVE-2024-40968" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40974" id="CVE-2024-40974" title="CVE-2024-40974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40983" id="CVE-2024-40983" title="CVE-2024-40983" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40984" id="CVE-2024-40984" title="CVE-2024-40984" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40987" id="CVE-2024-40987" title="CVE-2024-40987" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41004" id="CVE-2024-41004" title="CVE-2024-41004" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41005" id="CVE-2024-41005" title="CVE-2024-41005" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41007" id="CVE-2024-41007" title="CVE-2024-41007" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41009" id="CVE-2024-41009" title="CVE-2024-41009" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:lib/generic-radix-tree.c: Don&#39;t overflow in peek()When we started spreading new inode numbers throughout most of the 64bit inode space, that triggered some corner case bugs, in particularsome integer overflows related to the radix tree code. Oops.(CVE-2021-47432)In the Linux kernel, the following vulnerability has been resolved:scsi: ufs: Fix a deadlock in the error handlerThe 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_jtCall 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/0x30Fix this lockup by making ufshcd_exec_dev_cmd() allocate a reservedrequest.(CVE-2021-47622)In the Linux kernel, the following vulnerability has been resolved:net: dsa: seville: register the mdiobus under devresAs explained in commits:74b6d7d13307 (&#34;net: dsa: realtek: register the MDIO bus under devres&#34;)5135e96a3dd2 (&#34;net: dsa: don&#39;t allocate the slave_mii_bus using devres&#34;)mdiobus_free() will panic when called from devm_mdiobus_free() &lt;-devres_release_all() &lt;- __device_release_driver(), and that mdiobus wasnot previously unregistered.The Seville VSC9959 switch is a platform device, so the initial set ofconstraints 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 whichapplies 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 linkbetween 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, whichis: either use devres for both the mdiobus allocation and registration,or don&#39;t use devres at all.The seville driver has a code structure that could accommodate both themdiobus_unregister and mdiobus_free calls, but it has an externaldependency upon mscc_miim_setup() from mdio-mscc-miim.c, which callsdevm_mdiobus_alloc_size() on its behalf. So rather than restructuringthat, and exporting yet one more symbol mscc_miim_teardown(), let&#39;s workwith devres and replace of_mdiobus_register with the devres variant.When we use all-devres, we can ensure that devres doesn&#39;t free astill-registered bus (it either runs both callbacks, or none).(CVE-2022-48814)In the Linux kernel, the following vulnerability has been resolved:SUNRPC: lock against -&gt;sock changing during sysfs read-&gt;sock can be set to NULL asynchronously unless -&gt;recv_mutex is held.So it is important to hold that mutex.  Otherwise a sysfs read cantrigger an oops.Commit 17f09d3f619a (&#34;SUNRPC: Check if the xprt is connected beforehandling sysfs reads&#34;) appears to attempt to fix this problem, but itonly narrows the race window.(CVE-2022-48816)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: hci_core: Fix leaking sent_cmd skbsent_cmd memory is not freed before freeing hci_dev causing it to leakit contents.(CVE-2022-48844)In the Linux kernel, the following vulnerability has been resolved:smb: client: fix potential deadlock when releasing midsAll release_mid() callers seem to hold a reference of @mid so there isno need to call kref_put(&amp;mid-&gt;refcount, __release_mid) under@server-&gt;mid_lock spinlock.  If they don&#39;t, then an use-after-free bugwould have occurred anyways.By getting rid of such spinlock also fixes a potential deadlock asshown belowCPU 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)&#x9;&#x9;&#x9;&#x9;      spin_lock(&amp;server-&gt;mid_lock)  __release_mid()   smb2_find_smb_tcon()    spin_lock(&amp;cifs_tcp_ses_lock) *deadlock*(CVE-2023-52757)In the Linux kernel, the following vulnerability has been resolved:usb: config: fix iteration issue in &#39;usb_get_bos_descriptor()&#39;The BOS descriptor defines a root descriptor and is the base descriptor foraccessing a family of related descriptors.Function &#39;usb_get_bos_descriptor()&#39; encounters an iteration issue whenskipping the &#39;USB_DT_DEVICE_CAPABILITY&#39; descriptor type. This results inthe same descriptor being read repeatedly.To address this issue, a &#39;goto&#39; statement is introduced to ensure that thepointer and the amount read is updated correctly. This ensures that thefunction iterates to the next descriptor instead of reading the samedescriptor repeatedly.(CVE-2023-52781)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 immaturenetns.rpc_proc_register() was called in init_nfs_fs(), but its errorhas been ignored since at least the initial commit 1da177e4c3f4(&#34;Linux-2.6.12-rc2&#34;).Recently, commit d47151b79e32 (&#34;nfs: expose /proc/net/sunrpc/nfsin net namespaces&#34;) converted the procfs to per-netns and madethe 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 procdirectory and trigger the warning below.Let&#39;s handle the error of rpc_proc_register() properly in nfs_net_init().[0]:name &#39;nfs&#39;WARNING: CPU: 1 PID: 1710 at fs/proc/generic.c:711 remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711Modules linked in:CPU: 1 PID: 1710 Comm: syz-executor.2 Not tainted 6.8.0-12822-gcd51db110a7e #12Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:remove_proc_entry+0x1bb/0x2d0 fs/proc/generic.c:711Code: 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 ebRSP: 0018:ffffc9000c6d7ce0 EFLAGS: 00010286RAX: 0000000000000000 RBX: ffff8880422b8b00 RCX: ffffffff8110503cRDX: ffff888030652f00 RSI: ffffffff81105045 RDI: 0000000000000001RBP: 0000000000000000 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000001 R11: ffffffff81bb62cb R12: ffffffff84807ffcR13: ffff88804ad6fcc0 R14: ffffffff84807ffc R15: ffffffff85741ff8FS:  00007f30cfba8640(0000) GS:ffff88807dd00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ff51afe8000 CR3: 000000005a60a005 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call 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/0x4eRIP: 0033:0x7f30d0febe5dCode: 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 48RSP: 002b:00007f30cfba7cc8 EFLAGS: 00000246 ORIG_RAX: 0000000000000110RAX: ffffffffffffffda RBX: 00000000004bbf80 RCX: 00007f30d0febe5dRDX: 0000000000000000 RSI: 0000000000000000 RDI: 000000006c020600RBP: 00000000004bbf80 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000002R13: 000000000000000b R14: 00007f30d104c530 R15: 0000000000000000 &lt;/TASK&gt;(CVE-2024-36939)In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Ensure the copied buf is NUL terminatedCurrently, we allocate a count-sized kernel buffer and copy count fromuserspace to that buffer. Later, we use kstrtouint on this buffer but wedon&#39;t ensure that the string is terminated inside the buffer, this canlead to OOB read when using kstrtouint. Fix this issue by usingmemdup_user_nul instead of memdup_user.(CVE-2024-38559)In the Linux kernel, the following vulnerability has been resolved:drivers/perf: hisi: hns3: Fix out-of-bound access when valid event groupThe perf tool allows users to create event groups through followingcmd [1], but the driver does not check whether the array index is outof bounds when writing data to the event_group array. If the number ofevents in an event_group is greater than HNS3_PMU_MAX_HW_EVENTS, thememory 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 &#39;{pmu/event1/, ... ,pmu/event9/}(CVE-2024-38568)In the Linux kernel, the following vulnerability has been resolved:ecryptfs: Fix buffer size for tag 66 packetThe &#39;TAG 66 Packet Format&#39; description is missing the cipher code andchecksum fields that are packed into the message packet. As a result,the buffer allocated for the packet is 3 bytes too small andwrite_tag_66_packet() will write up to 3 bytes past the end of thebuffer.Fix this by increasing the size of the allocation so the whole packetwill 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-38578)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 detected6.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:697but 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:697which 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/0x7fother 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-38589)In the Linux kernel, the following vulnerability has been resolved:ALSA: timer: Set lower bound of start tick timeCurrently ALSA timer doesn&#39;t have the lower limit of the start ticktime, and it allows a very small size, e.g. 1 tick with 1ns resolutionfor hrtimer.  Such a situation may lead to an unexpected RCU stall,where  the callback repeatedly queuing the expire update, as reportedby fuzzer.This patch introduces a sanity check of the timer start tick time, sothat 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 issmall enough but can still work somehow.(CVE-2024-38618)In the Linux kernel, the following vulnerability has been resolved:usb-storage: alauda: Check whether the media is initializedThe member &#34;uzonesize&#34; of struct alauda_info will remain 0if alauda_init_media() fails, potentially causing divide errorsin alauda_read_data() and alauda_write_lba().- Add a member &#34;media_initialized&#34; 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-2024-38619)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix nilfs_empty_dir() misjudgment and long loop on I/O errorsThe error handling in nilfs_empty_dir() when a directory folio/page readfails is incorrect, as in the old ext2 implementation, and if thefolio/page cannot be read or nilfs_check_folio() fails, it will falselydetermine the directory as empty and corrupt the file system.In addition, since nilfs_empty_dir() does not immediately return on afailed folio/page read, but continues to loop, this can cause a long loopwith I/O if i_size of the directory&#39;s inode is also corrupted, causing thelog writer thread to wait and hang, as reported by syzbot.Fix these issues by making nilfs_empty_dir() immediately return a falsevalue (0) if it fails to get a directory folio/page.(CVE-2024-39469)In the Linux kernel, the following vulnerability has been resolved:xfs: fix log recovery buffer allocation for the legacy h_size fixupCommit a70f9fe52daa (&#34;xfs: detect and handle invalid iclog size set bymkfs&#34;) added a fixup for incorrect h_size values used for the initialumount record in old xfsprogs versions.  Later commit 0c771b99d6c9(&#34;xfs: clean up calculation of LR header blocks&#34;) 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-39472)In the Linux kernel, the following vulnerability has been resolved:ima: Fix use-after-free on a dentry&#39;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&#39;s inode,rename_lock), but none of those are met at any of the sites. Take a stablesnapshot of the name instead.(CVE-2024-39494)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 usedas an index without sanitization.This change ensures that the event index is sanitized to mitigate anypossibility of speculative information leaks.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.Only compile tested, no access to HW.(CVE-2024-39499)In the Linux kernel, the following vulnerability has been resolved:drm/komeda: check for error-valued pointerkomeda_pipeline_get_state() may return an error-valued pointer, thuscheck the pointer for negative or null value before dereferencing.(CVE-2024-39505)In the Linux kernel, the following vulnerability has been resolved:USB: class: cdc-wdm: Fix CPU lockup caused by excessive log messagesThe syzbot fuzzer found that the interrupt-URB completion callback inthe cdc-wdm driver was taking too long, and the driver&#39;s immediateresubmission of interrupt URBs with -EPROTO status combined with thedummy-hcd emulation to cause a CPU lockup:cdc_wdm 1-1:1.0: nonzero urb status received: -71cdc_wdm 1-1:1.0: wdm_int_callback - 0 byteswatchdog: BUG: soft lockup - CPU#0 stuck for 26s! [syz-executor782:6625]CPU#0 Utilization every 4s during lockup:&#x9;#1:  98% system,&#x9;  0% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#x9;#2:  98% system,&#x9;  0% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#x9;#3:  98% system,&#x9;  0% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#x9;#4:  98% system,&#x9;  0% softirq,&#x9;  3% hardirq,&#x9;  0% idle&#x9;#5:  98% system,&#x9;  1% softirq,&#x9;  3% hardirq,&#x9;  0% idleModules linked in:irq event stamp: 73096hardirqs 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:2994hardirqs 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:551softirqs 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:582softirqs last disabled at (73043): [&lt;ffff800080020de8&gt;] __do_softirq+0x14/0x20 kernel/softirq.c:588CPU: 0 PID: 6625 Comm: syz-executor782 Tainted: G        W          6.10.0-rc2-syzkaller-g8867bbd4a056 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Testing showed that the problem did not occur if the two errormessages -- the first two lines above -- were removed; apparently addingmaterial to the kernel log takes a surprisingly large amount of time.In any case, the best approach for preventing these lockups and toavoid spamming the log with thousands of error messages per second isto ratelimit the two dev_err() calls.  Therefore we replace them withdev_err_ratelimited().(CVE-2024-40904)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 clearsthe value in rt6_get_pcpu_route().Add a READ_ONCE() to prevent this race.Also add rcu_read_lock()/rcu_read_unlock() becausewe rely on RCU protection while dereferencing pcpu_rt.[1]Oops: general protection fault, probably for non-canonical address 0xdffffc0000000012: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000090-0x0000000000000097]CPU: 0 PID: 7543 Comm: kworker/u8:17 Not tainted 6.10.0-rc1-syzkaller-00013-g2bfcfd584ff5 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: netns cleanup_net RIP: 0010:__fib6_drop_pcpu_from.part.0+0x10a/0x370 net/ipv6/ip6_fib.c:984Code: 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 48RSP: 0018:ffffc900040df070 EFLAGS: 00010206RAX: 0000000000000012 RBX: 0000000000000001 RCX: ffffffff89932e16RDX: ffff888049dd1e00 RSI: ffffffff89932d7c RDI: 0000000000000091RBP: dffffc0000000000 R08: 0000000000000005 R09: 0000000000000007R10: 0000000000000001 R11: 0000000000000006 R12: ffff88807fa080b8R13: fffffbfff1a9a07d R14: ffffed100ff41022 R15: 0000000000000001FS:  0000000000000000(0000) GS:ffff8880b9200000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b32c26000 CR3: 000000005d56e000 CR4: 00000000003526f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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-40905)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 tosynchronizes with ieee80211_tx_h_unicast_ps_buf() which is called fromsoftirq context. However using only spin_lock() to get sta-&gt;ps_lock inieee80211_sta_ps_deliver_wakeup() does not prevent softirq to executeon this same CPU, to run ieee80211_tx_h_unicast_ps_buf() and try totake this same lock ending in deadlock. Below is an example of rcu stallthat 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/0x150Using spin_lock_bh()/spin_unlock_bh() instead prevents softirq to raiseon the same CPU that is holding the lock.(CVE-2024-40912)In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: check n_ssids before accessing the ssidsIn some versions of cfg80211, the ssids poinet might be a valid one eventhough n_ssids is 0. Accessing the pointer in this case will cuase anout-of-bound access. Fix this by checking n_ssids first.(CVE-2024-40929)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-40932)In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don&#39;t read past the mfuart notifcationIn case the firmware sends a notification that claims it has more datathan it has, we will read past that was allocated for the notification.Remove the print of the buffer, we won&#39;t see it by default. If needed,we can see the content with tracing.This was reported by KFENCE.(CVE-2024-40941)In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix races between hole punching and AIO+DIOAfter commit &#34;ocfs2: return real error code in ocfs2_dio_wr_get_block&#34;,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 = -3fio: 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 unwrittenextents to a list.  extents are also inserted into extent tree inocfs2_write_begin_nolock.  Then another thread call fallocate to puch ahole at one of the unwritten extent.  The extent at cpos was removed byocfs2_remove_extent().  At end io worker thread, ocfs2_search_extent_listfound there is no such extent at the cpos.    T1                        T2                T3                              inode lock                                ...                                insert extents                                ...                              inode unlockocfs2_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_semIn 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 likeext4.(CVE-2024-40943)In the Linux kernel, the following vulnerability has been resolved:MIPS: Octeon: Add PCIe link status checkThe standard PCIe configuration read-write interface is used toaccess the configuration space of the peripheral PCIe devicesof the mips processor after the PCIe link surprise down, it cangenerate kernel panic caused by &#34;Data bus error&#34;. So it isnecessary to add PCIe link status check for system protection.When the PCIe link is down or in training, assigning a valueof 0 to the configuration address can prevent read-write behaviorto the configuration space of peripheral PCIe devices, therebypreventing kernel panic.(CVE-2024-40968)In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Enforce hcall result buffer validity and sizeplpar_hcall(), plpar_hcall9(), and related functions expect callers toprovide valid result buffers of certain minimum size. Currently thisis communicated only through comments in the code and the compiler hasno 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 stackcorruption at runtime when plpar_hcall9() stores results past the endof the array. (To be clear this is a contrived example and I have notfound a real instance yet.)To make this class of error less likely, we can use explicitly-sizedarray parameters instead of pointers in the declarations for the hcallAPIs. When compiled with -Warray-bounds[1], the code above nowprovokes 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 (&#34;gcc: disable &#39;-Warray-bounds&#39; for gcc-13 too&#34;) and    related changes.(CVE-2024-40974)In the Linux kernel, the following vulnerability has been resolved:tipc: force a dst refcount before doing decryptionAs it says in commit 3bc07321ccc2 (&#34;xfrm: Force a dst refcount beforeentering the xfrm type handlers&#34;):&#34;Crypto requests might return asynchronous. In this case we leave the rcu protected region, so force a refcount on the skb&#39;s destination entry before we enter the xfrm type input/output handlers.&#34;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-40983)In the Linux kernel, the following vulnerability has been resolved:ACPICA: Revert &#34;ACPICA: avoid Info: mapping multiple BARs. Your kernel is fine.&#34;Undo the modifications made in commit d410ee5109a1 (&#34;ACPICA: avoid&#34;Info: mapping multiple BARs. Your kernel is fine.&#34;&#34;). The initialpurpose of this commit was to stop memory mappings for operationregions from overlapping page boundaries, as it can trigger warningsif different page attributes are present.However, it was found that when this situation arises, mappingcontinues until the boundary&#39;s end, but there is still an attempt toread/write the entire length of the map, leading to a NULL pointerdeference. For example, if a four-byte mapping request is made butonly one byte is mapped because it hits the current page boundary&#39;send, a four-byte read/write attempt is still made, resulting in a NULLpointer deference.Instead, map the entire length, as the ACPI specification does notmandate that it must be within the same page boundary. It ispermissible for it to be mapped across different regions.(CVE-2024-40984)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.(CVE-2024-40987)In the Linux kernel, the following vulnerability has been resolved:tracing: Build event generation tests only as modulesThe 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 thoseare designed for playing as modules.If we make those modules as built-in, those events are left locked in thekernel, and never be removed. This causes kprobe event self-test failureas 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 arefailed too.To avoid these issues, build these tests only as modules.(CVE-2024-41004)In the Linux kernel, the following vulnerability has been resolved:netpoll: Fix race condition in netpoll_owner_activeKCSAN detected a race condition in netpoll:&#x9;BUG: KCSAN: data-race in net_rx_action / netpoll_send_skb&#x9;write (marked) to 0xffff8881164168b0 of 4 bytes by interrupt on cpu 10:&#x9;net_rx_action (./include/linux/netpoll.h:90 net/core/dev.c:6712 net/core/dev.c:6822)&lt;snip&gt;&#x9;read to 0xffff8881164168b0 of 4 bytes by task 1 on cpu 2:&#x9;netpoll_send_skb (net/core/netpoll.c:319 net/core/netpoll.c:345 net/core/netpoll.c:393)&#x9;netpoll_send_udp (net/core/netpoll.c:?)&lt;snip&gt;&#x9;value changed: 0x0000000a -&gt; 0xffffffffThis happens because netpoll_owner_active() needs to check if thecurrent CPU is the owner of the lock, touching napi-&gt;poll_ownernon atomically. The -&gt;poll_owner field contains the current CPU holdingthe lock.Use an atomic read to check if the poll owner is the current CPU.(CVE-2024-41005)In the Linux kernel, the following vulnerability has been resolved:tcp: avoid too many retransmit packetsIf a TCP socket is using TCP_USER_TIMEOUT, and the other peerretracted its window to zero, tcp_retransmit_timer() canretransmit a packet every two jiffies (2 ms for HZ=1000),for about 4 minutes after TCP_USER_TIMEOUT has &#39;expired&#39;.The fix is to make sure tcp_rtx_probe0_timed_out() takesicsk-&gt;icsk_user_timeout into account.Before blamed commit, the socket would not timeout aftericsk-&gt;icsk_user_timeout, but would use standard exponentialbackoff for the retransmits.Also worth noting that before commit e89688e3e978 (&#34;net: tcp:fix unexcepted socket die when snd_wnd is 0&#34;), the issuewould last 2 minutes instead of 4.(CVE-2024-41007)In the Linux kernel, the following vulnerability has been resolved:bpf: Fix overrunning reservations in ringbufThe BPF ring buffer internally is implemented as a power-of-2 sized circularbuffer, with two logical and ever-increasing counters: consumer_pos is theconsumer counter to show which logical position the consumer consumed thedata, and producer_pos which is the producer counter denoting the amount ofdata reserved by all producers.Each time a record is reserved, the producer that &#34;owns&#34; the record willsuccessfully advance producer counter. In user space each time a record isread, the consumer of the data advanced the consumer counter once it finishedprocessing. Both counters are stored in separate pages so that from userspace, the producer counter is read-only and the consumer counter is read-write.One aspect that simplifies and thus speeds up the implementation of bothproducers and consumers is how the data area is mapped twice contiguouslyback-to-back in the virtual memory, allowing to not take any special measuresfor samples that have to wrap around at the end of the circular buffer dataarea, because the next page after the last data page would be first data pageagain, and thus the sample will still appear completely contiguous in virtualmemory.Each record has a struct bpf_ringbuf_hdr { u32 len; u32 pg_off; } header forbook-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 howeverpossible to make a second allocated memory chunk overlapping with the firstchunk and as a result, the BPF program is now able to edit first chunk&#39;sheader.For example, consider the creation of a BPF_MAP_TYPE_RINGBUF map with sizeof 0x4000. Next, the consumer_pos is modified to 0x3000 /before/ a call tobpf_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, letsallocate a chunk B with size 0x3000. This will succeed because consumer_poswas 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 ableto edit [0x3010,0x6010]. Due to the ring buffer memory layout mentionedearlier, the ranges [0x0,0x4000] and [0x4000,0x8000] point to the same datapages. This means that chunk B at [0x4000,0x4008] is chunk A&#39;s header.bpf_ringbuf_submit() / bpf_ringbuf_discard() use the header&#39;s pg_off to thenlocate the bpf_ringbuf itself via bpf_ringbuf_restore_from_rec(). Once chunkB modified chunk A&#39;s header, then bpf_ringbuf_commit() refers to the wrongpage and could cause a crash.Fix it by calculating the oldest pending_pos and check whether the rangefrom the oldest outstanding record to the newest would span beyond the ringbuffer size. If that is the case, then reject the request. We&#39;ve tested withthe 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, itis still not significantly enough to matter.(CVE-2024-41009)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.86.0.167.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.86.0.167.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.86.0.167.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1905</id>
          <title>An update for dnsmasq is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49441" id="CVE-2023-49441" title="CVE-2023-49441" type="cve"></reference>
          </references>
          <description>dnsmasq 2.9 is vulnerable to Integer Overflow via forward_query.(CVE-2023-49441)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="dnsmasq" release="8.oe2203sp1" version="2.86">
                         <filename>dnsmasq-2.86-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dnsmasq-debuginfo" release="8.oe2203sp1" version="2.86">
                         <filename>dnsmasq-debuginfo-2.86-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dnsmasq-debugsource" release="8.oe2203sp1" version="2.86">
                         <filename>dnsmasq-debugsource-2.86-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dnsmasq-help" release="8.oe2203sp1" version="2.86">
                         <filename>dnsmasq-help-2.86-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dnsmasq" release="8.oe2203sp1" version="2.86">
                         <filename>dnsmasq-2.86-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dnsmasq-debuginfo" release="8.oe2203sp1" version="2.86">
                         <filename>dnsmasq-debuginfo-2.86-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dnsmasq-debugsource" release="8.oe2203sp1" version="2.86">
                         <filename>dnsmasq-debugsource-2.86-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dnsmasq-help" release="8.oe2203sp1" version="2.86">
                         <filename>dnsmasq-help-2.86-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1907</id>
          <title>An update for openjdk-11 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"></reference>
          </references>
          <description>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-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 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-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 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-21140)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-21144)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-21145)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).(CVE-2024-21147)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debuginfo" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-debuginfo-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-debugsource" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-debugsource-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-demo-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-demo-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-devel-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-devel-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-headless-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-headless-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-javadoc-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-javadoc-zip" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-jmods-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-jmods-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-slowdebug-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-src-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="java-11-openjdk-src-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debuginfo" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-debuginfo-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-debugsource" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-debugsource-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-demo-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-demo-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-demo-slowdebug-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-devel-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-devel-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-devel-slowdebug-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-headless-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-headless-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-headless-slowdebug-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-javadoc-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-javadoc-zip" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-javadoc-zip-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-jmods-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-jmods-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-jmods-slowdebug-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-slowdebug-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-src-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="java-11-openjdk-src-slowdebug" release="0.oe2203sp1" version="11.0.24.8">
                         <filename>java-11-openjdk-src-slowdebug-11.0.24.8-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1913</id>
          <title>An update for assimp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40724" id="CVE-2024-40724" title="CVE-2024-40724" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-40724)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="assimp" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-5.2.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debuginfo" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debugsource" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-devel" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-devel-5.2.4-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="assimp-help" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-help-5.2.4-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-assimp" release="2.oe2203sp1" version="5.2.4">
                         <filename>python3-assimp-5.2.4-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-5.2.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debuginfo" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debugsource" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-devel" release="2.oe2203sp1" version="5.2.4">
                         <filename>assimp-devel-5.2.4-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1914</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-07-26"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5535" id="CVE-2024-5535" title="CVE-2024-5535" type="cve"></reference>
          </references>
          <description>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 &#34;no overlap&#34;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.(CVE-2024-5535)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="19.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="19.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="19.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="19.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="19.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="19.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="19.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="19.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="19.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="19.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1919</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20996" id="CVE-2024-20996" title="CVE-2024-20996" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21135" id="CVE-2024-21135" title="CVE-2024-21135" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21162" id="CVE-2024-21162" title="CVE-2024-21162" type="cve"></reference>
          </references>
          <description>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-20996)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-21135)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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1931</id>
          <title>An update for python-setuptools is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6345" id="CVE-2024-6345" title="CVE-2024-6345" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-6345)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-setuptools" release="6.oe2203sp1" version="59.4.0">
                         <filename>python3-setuptools-59.4.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-setuptools" release="6.oe2203sp1" version="59.4.0">
                         <filename>python-setuptools-59.4.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-setuptools-help" release="6.oe2203sp1" version="59.4.0">
                         <filename>python-setuptools-help-59.4.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1935</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21127" id="CVE-2024-21127" title="CVE-2024-21127" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21130" id="CVE-2024-21130" title="CVE-2024-21130" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21134" id="CVE-2024-21134" title="CVE-2024-21134" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21157" id="CVE-2024-21157" title="CVE-2024-21157" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21160" id="CVE-2024-21160" title="CVE-2024-21160" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21165" id="CVE-2024-21165" title="CVE-2024-21165" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21166" id="CVE-2024-21166" title="CVE-2024-21166" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21177" id="CVE-2024-21177" title="CVE-2024-21177" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21179" id="CVE-2024-21179" title="CVE-2024-21179" type="cve"></reference>
          </references>
          <description>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: 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-21130)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-21134)Vulnerability in the MySQL Server product of Oracle MySQL (component: InnoDB).  Supported versions that are affected are 8.0.36 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-21157)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-21160)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-21165)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. 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-2024-21166)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-21177)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-21179)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1941</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47205" id="CVE-2021-47205" title="CVE-2021-47205" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48703" id="CVE-2022-48703" title="CVE-2022-48703" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48780" id="CVE-2022-48780" title="CVE-2022-48780" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48859" id="CVE-2022-48859" title="CVE-2022-48859" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52679" id="CVE-2023-52679" title="CVE-2023-52679" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26924" id="CVE-2024-26924" title="CVE-2024-26924" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26925" id="CVE-2024-26925" title="CVE-2024-26925" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27010" id="CVE-2024-27010" title="CVE-2024-27010" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-34777" id="CVE-2024-34777" title="CVE-2024-34777" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35808" id="CVE-2024-35808" title="CVE-2024-35808" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35837" id="CVE-2024-35837" title="CVE-2024-35837" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35899" id="CVE-2024-35899" title="CVE-2024-35899" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35931" id="CVE-2024-35931" title="CVE-2024-35931" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36923" id="CVE-2024-36923" title="CVE-2024-36923" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37078" id="CVE-2024-37078" title="CVE-2024-37078" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38548" id="CVE-2024-38548" title="CVE-2024-38548" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38567" id="CVE-2024-38567" title="CVE-2024-38567" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38607" id="CVE-2024-38607" title="CVE-2024-38607" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38611" id="CVE-2024-38611" title="CVE-2024-38611" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38621" id="CVE-2024-38621" title="CVE-2024-38621" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39475" id="CVE-2024-39475" title="CVE-2024-39475" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39476" id="CVE-2024-39476" title="CVE-2024-39476" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39484" id="CVE-2024-39484" title="CVE-2024-39484" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39506" id="CVE-2024-39506" title="CVE-2024-39506" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39508" id="CVE-2024-39508" title="CVE-2024-39508" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40915" id="CVE-2024-40915" title="CVE-2024-40915" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40945" id="CVE-2024-40945" title="CVE-2024-40945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40947" id="CVE-2024-40947" title="CVE-2024-40947" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40956" id="CVE-2024-40956" title="CVE-2024-40956" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40960" id="CVE-2024-40960" title="CVE-2024-40960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40967" id="CVE-2024-40967" title="CVE-2024-40967" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40972" id="CVE-2024-40972" title="CVE-2024-40972" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40980" id="CVE-2024-40980" title="CVE-2024-40980" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40981" id="CVE-2024-40981" title="CVE-2024-40981" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40995" id="CVE-2024-40995" title="CVE-2024-40995" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41011" id="CVE-2024-41011" title="CVE-2024-41011" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:clk: sunxi-ng: Unregister clocks/resets when unbindingCurrently, unbinding a CCU driver unmaps the device&#39;s MMIO region, whileleaving its clocks/resets and their providers registered. This can causea page fault later when some clock operation tries to perform MMIO. Fixthis 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 thecorrect owner (the specific platform driver) for the clocks and resets.Early OF clock providers are never unregistered, and limited errorhandling is possible, so they are mostly unchanged. The error reportingis made more consistent by moving the message inside of_sunxi_ccu_probe.(CVE-2021-47205)In the Linux kernel, the following vulnerability has been resolved:thermal/int340x_thermal: handle data_vault when the value is ZERO_SIZE_PTRIn some case, the GDDV returns a package with a buffer which haszero length. It causes that kmemdup() returns ZERO_SIZE_PTR (0x10).Then the data_vault_read() got NULL point dereference problem whenaccessing the 0x10 value in data_vault.[   71.024560] BUG: kernel NULL pointer dereference, address:0000000000000010This patch uses ZERO_OR_NULL_PTR() for checking ZERO_SIZE_PTR orNULL value in data_vault.(CVE-2022-48703)In the Linux kernel, the following vulnerability has been resolved:net/smc: Avoid overwriting the copies of clcsock callback functionsThe callback functions of clcsock will be saved and replaced duringthe fallback. But if the fallback happens more than once, then thecopies of these callback functions will be overwritten incorrectly,resulting in a loop call issue:clcsk-&gt;sk_error_report |- smc_fback_error_report() &lt;------------------------------|     |- smc_fback_forward_wakeup()                          | (loop)         |- clcsock_callback()  (incorrectly overwritten)   |             |- smc-&gt;clcsk_error_report() ------------------|So this patch fixes the issue by saving these function pointers onlyonce in the fallback and avoiding overwriting.(CVE-2022-48780)In the Linux kernel, the following vulnerability has been resolved:net: marvell: prestera: Add missing of_node_put() in prestera_switch_set_base_mac_addrThis node pointer is returned by of_find_compatible_node() withrefcount incremented. Calling of_node_put() to aovid the refcount leak.(CVE-2022-48859)In the Linux kernel, the following vulnerability has been resolved:of: Fix double free in of_parse_phandle_with_args_mapIn of_parse_phandle_with_args_map() the inner loop thatiterates through the map entries calls of_node_put(new)to free the reference acquired by the previous iterationof the inner loop. This assumes that the value of &#34;new&#34; isNULL on the first iteration of the inner loop.Make sure that this is true in all iterations of the outerloop by setting &#34;new&#34; to NULL after its value is assigned to &#34;cur&#34;.Extend the unittest to detect the double free and add an additionaltest case that actually triggers this path.(CVE-2023-52679)In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_set_pipapo: do not free live elementPablo reports a crash with large batches of elements with aback-to-back add/remove pattern.  Quoting Pablo:  add_elem(&#34;00000000&#34;) timeout 100 ms  ...  add_elem(&#34;0000000X&#34;) timeout 100 ms  del_elem(&#34;0000000X&#34;) &lt;---------------- delete one that was just added  ...  add_elem(&#34;00005000&#34;) 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 arule that maps to a non-deactivated element.Removal happens in two steps, first we do a lookup for key k and return theto-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 oneelement that share the same key.This can happen if we insert an element into a set when the set alreadyholds an element with same key, but the element mapping to the existingkey 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 becomesunreachable.The element that got deactivated (and will be freed later) willremain reachable in the set data structure, this can result ina crash when such an element is retrieved during lookup (stalepointer).Add a check that the fully matching key does in fact map to the elementthat 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 removefunction must not ever be called with an invisible/unreachable/non-existentelement.v2: avoid uneeded temporary variable (Stefano)(CVE-2024-26924)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: release mutex after nft_gc_seq_end from abort pathThe commit mutex should not be released during the critical sectionbetween nft_gc_seq_begin() and nft_gc_seq_end(), otherwise, async GCworker could collect expired objects and get the released commit lockwithin the same GC sequence.nf_tables_module_autoload() temporarily releases the mutex to loadmodule 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-26925)In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix mirred deadlock on device recursionWhen the mirred action is used on a classful egress qdisc and a packet ismirrored 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 recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \     action mirred egress redirect dev eth0Another example(eth0-&gt;eth1-&gt;eth0) to recreatetc qdisc add dev eth0 root handle 1: htb default 30tc filter add dev eth0 handle 1: protocol ip prio 2 matchall \     action mirred egress redirect dev eth1tc qdisc add dev eth1 root handle 1: htb default 30tc filter add dev eth1 handle 1: protocol ip prio 2 matchall \     action mirred egress redirect dev eth0We fix this by adding an owner field (CPU id) to struct Qdisc set afterroot qdisc is entered. When the softirq enters it a second time, if theqdisc owner is the same CPU, the packet is dropped to break the loop.(CVE-2024-27010)In the Linux kernel, the following vulnerability has been resolved:dma-mapping: benchmark: fix node id validationWhile validating node ids in map_benchmark_ioctl(), node_possible() maybe provided with invalid argument outside of [0,MAX_NUMNODES-1] rangeleading 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/971CPU: 7 PID: 971 Comm: dma_map_benchma Not tainted 6.9.0-rc6 #37Hardware 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 aspecial valid case meaning that benchmarking kthreads won&#39;t be bound to acpuset of a given node.Found by Linux Verification Center (linuxtesting.org).(CVE-2024-34777)In the Linux kernel, the following vulnerability has been resolved:md/dm-raid: don&#39;t call md_reap_sync_thread() directlyCurrently md_reap_sync_thread() is called from raid_message() directlywithout holding &#39;reconfig_mutex&#39;, this is definitely unsafe becausemd_reap_sync_thread() can change many fields that is protected by&#39;reconfig_mutex&#39;.However, hold &#39;reconfig_mutex&#39; here is still problematic because thiswill cause deadlock, for example, commit 130443d60b1b (&#34;md: refactoridle/frozen_sync_thread() to fix deadlock&#34;).Fix this problem by using stop_sync_thread() to unregister sync_thread,like md/raid did.(CVE-2024-35808)In the Linux kernel, the following vulnerability has been resolved:net: mvpp2: clear BM pool before initializationRegister value persist after booting the kernel usingkexec which results in kernel panic. Thus clear theBM pool registers before initialisation to fix the issue.(CVE-2024-35837)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: flush pending destroy work before exit_net releaseSimilar to 2c9f0293280e (&#34;netfilter: nf_tables: flush pending destroywork before netlink notifier&#34;) to address a race between exit_net andthe destroy workqueue.The trace below shows an element to be released via destroy workqueuewhile exit_net path (triggered via module removal) has already releasedthe 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+0x4730x1e033 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-35899)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Skip do PCI error slot reset during RAS recoveryWhy:    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/0x3d0How:    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-35931)In the Linux kernel, the following vulnerability has been resolved:fs/9p: fix uninitialized values during inode evictIf an iget fails due to not being able to retrieve informationfrom the server then the inode structure is only partiallyinitialized.  When the inode gets evicted, references touninitialized structures (like fscache cookies) were beingmade.This patch checks for a bad_inode before doing anything otherthan clearing the inode from the cache.  Since the inode isbad, it shouldn&#39;t have any state associated with it that needsto be written back (and there really isn&#39;t a way to completethose anyways).(CVE-2024-36923)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix potential kernel bug due to lack of writeback flag waitingDestructive writes to a block device on which nilfs2 is mounted can causea kernel bug in the folio/page writeback start routine or writeback endroutine (__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 summaryblocks or a super root block that use the backing device&#39;s page cache, itdoes not wait for the ongoing folio/page writeback, resulting in aninconsistent writeback state.Fix this issue by waiting for ongoing writebacks when puttingfolios/pages on the backing device into writeback state.(CVE-2024-37078)In the Linux kernel, the following vulnerability has been resolved:drm: bridge: cdns-mhdp8546: Fix possible null pointer dereferenceIn cdns_mhdp_atomic_enable(), the return value of drm_mode_duplicate() isassigned to mhdp_state-&gt;current_mode, and there is a dereference of it indrm_mode_set_name(), which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate().Fix this bug add a check of mhdp_state-&gt;current_mode.(CVE-2024-38548)In the Linux kernel, the following vulnerability has been resolved:wifi: carl9170: add a proper sanity check for endpointsSyzkaller reports [1] hitting a warning which is caused by presenceof a wrong endpoint type at the URB sumbitting stage. While therewas a check for a specific 4th endpoint, since it can switch typesbetween bulk and interrupt, other endpoints are trusted implicitly.Similar warning is triggered in a couple of other syzbot issues [2].Fix the issue by doing a comprehensive check of all endpointstaking into account difference between high- and full-speedconfiguration.[1] Syzkaller report:...WARNING: CPU: 0 PID: 4721 at drivers/usb/core/urb.c:504 usb_submit_urb+0xed6/0x1880 drivers/usb/core/urb.c:504...Call Trace: &lt;TASK&gt; carl9170_usb_send_rx_irq_urb+0x273/0x340 drivers/net/wireless/ath/carl9170/usb.c:504 carl9170_usb_init_device drivers/net/wireless/ath/carl9170/usb.c:939 [inline] carl9170_usb_firmware_finish drivers/net/wireless/ath/carl9170/usb.c:999 [inline] carl9170_usb_firmware_step2+0x175/0x240 drivers/net/wireless/ath/carl9170/usb.c:1028 request_firmware_work_func+0x130/0x240 drivers/base/firmware_loader/main.c:1107 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:308 &lt;/TASK&gt;[2] Related syzkaller crashes:(CVE-2024-38567)In the Linux kernel, the following vulnerability has been resolved:macintosh/via-macii: Fix &#34;BUG: sleeping function called from invalid context&#34;The via-macii ADB driver calls request_irq() after disabling hardinterrupts. But disabling interrupts isn&#39;t necessary here because theVIA shift register interrupt was masked during VIA1 initialization.(CVE-2024-38607)In the Linux kernel, the following vulnerability has been resolved:media: i2c: et8ek8: Don&#39;t strip remove function when driver is builtinUsing __exit for the remove function results in the remove callbackbeing discarded with CONFIG_VIDEO_ET8EK8=y. When such a device getsunbound (e.g. using sysfs or hotplug), the driver is just removedwithout the cleanup being performed. This results in resource leaks. Fixit by compiling in the remove callback unconditionally.This also fixes a W=1 modpost warning:&#x9;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-38611)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 lengthof the buffer.  The -&gt;bytesused is how many bytes we have copied thusfar.  When the condition is reversed that means the result of thesubtraction is always negative but since it&#39;s unsigned then the resultis a very high positive value.  That means the overflow check is nevertrue.Additionally, the -&gt;bytesused doesn&#39;t actually work for this purposebecause we&#39;re not writing to &#34;buf-&gt;mem + buf-&gt;bytesused&#34;.  Instead, themath to calculate the destination where we are writing is a bitinvolved.  You calculate the number of full lines already written,multiply by two, skip a line if necessary so that we start on an oddnumbered line, and add the offset into the line.To fix this buffer overflow, just take the actual destination where weare writing, if the offset is already out of bounds print an error andreturn.  Otherwise, write up to buf-&gt;length bytes.(CVE-2024-38621)In the Linux kernel, the following vulnerability has been resolved:fbdev: savage: Handle err return when savagefb_check_var failedThe commit 04e5eac8f3ab(&#34;fbdev: savage: Error out if pixclock equals zero&#34;)checks the value of pixclock to avoid divide-by-zero error. Howeverthe function savagefb_probe doesn&#39;t handle the error return ofsavagefb_check_var. When pixclock is 0, it will cause divide-by-zero error.(CVE-2024-39475)In the Linux kernel, the following vulnerability has been resolved:md/raid5: fix deadlock that raid5d() wait for itself to clear MD_SB_CHANGE_PENDINGXiao reported that lvm2 test lvconvert-raid-takeover.sh can hang withsmall possibility, the root cause is exactly the same as commitbed9e27baf52 (&#34;Revert &#34;md/raid5: Wait for MD_SB_CHANGE_PENDING in raid5d&#34;&#34;)However, Dan reported another hang after that, and junxiao investigatedthe problem and found out that this is caused by plugged bio can&#39;t issuefrom raid5d().Current implementation in raid5d() has a weird dependence:1) md_check_recovery() from raid5d() must hold &#39;reconfig_mutex&#39; to clear   MD_SB_CHANGE_PENDING;2) raid5d() handles IO in a deadloop, until all IO are issued;3) IO from raid5d() must wait for MD_SB_CHANGE_PENDING to be cleared;This behaviour is introduce before v2.6, and for consequence, if othercontext hold &#39;reconfig_mutex&#39;, and md_check_recovery() can&#39;t updatesuper_block, then raid5d() will waste one cpu 100% by the deadloop, until&#39;reconfig_mutex&#39; is released.Refer to the implementation from raid1 and raid10, fix this problem byskipping issue IO if MD_SB_CHANGE_PENDING is still set aftermd_check_recovery(), daemon thread will be woken up when &#39;reconfig_mutex&#39;is released. Meanwhile, the hang problem will be fixed as well.(CVE-2024-39476)In the Linux kernel, the following vulnerability has been resolved:mmc: davinci: Don&#39;t strip remove function when driver is builtinUsing __exit for the remove function results in the remove callback beingdiscarded with CONFIG_MMC_DAVINCI=y. When such a device gets unbound (e.g.using sysfs or hotplug), the driver is just removed without the cleanupbeing performed. This results in resource leaks. Fix it by compiling in theremove callback unconditionally.This also fixes a W=1 modpost warning:WARNING: modpost: drivers/mmc/host/davinci_mmc: section mismatch inreference: davinci_mmcsd_driver+0x10 (section: .data) -&gt;davinci_mmcsd_remove (section: .exit.text)(CVE-2024-39484)In the Linux kernel, the following vulnerability has been resolved:liquidio: Adjust a NULL pointer handling path in lio_vf_rep_copy_packetIn 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 looksstrange and could lead to null pointer dereference.lio_vf_rep_copy_packet() call trace looks like:&#x9;octeon_droq_process_packets&#x9; octeon_droq_fast_process_packets&#x9;  octeon_droq_dispatch_pkt&#x9;   octeon_create_recv_info&#x9;    ...search in the dispatch_list...&#x9;     -&gt;disp_fn(rdisp-&gt;rinfo, ...)&#x9;      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&#39;t solve potential problem.But I guess the author had reason to add a check and I have no such cardand can&#39;t do real test.In addition, the code in the function liquidio_push_packet() inliquidio/lio_core.c does exactly the same.Based on this, I consider the most acceptable compromise solution toadjust this issue by moving skb_add_rx_frag() into conditional scope.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-39506)In the Linux kernel, the following vulnerability has been resolved:io_uring/io-wq: Use set_bit() and test_bit() at worker-&gt;flagsUtilize set_bit() and test_bit() on worker-&gt;flags within io_uring/io-wqto address potential data races.The structure io_worker-&gt;flags may be accessed through various datapaths, leading to concurrency issues. When KCSAN is enabled, it revealsdata races occurring in io_worker_handle_work andio_wq_activate_free_worker functions.&#x9; BUG: KCSAN: data-race in io_worker_handle_work / io_wq_activate_free_worker&#x9; write to 0xffff8885c4246404 of 4 bytes by task 49071 on cpu 28:&#x9; io_worker_handle_work (io_uring/io-wq.c:434 io_uring/io-wq.c:569)&#x9; io_wq_worker (io_uring/io-wq.c:?)&lt;snip&gt;&#x9; read to 0xffff8885c4246404 of 4 bytes by task 49024 on cpu 5:&#x9; io_wq_activate_free_worker (io_uring/io-wq.c:? io_uring/io-wq.c:285)&#x9; io_wq_enqueue (io_uring/io-wq.c:947)&#x9; io_queue_iowq (io_uring/io_uring.c:524)&#x9; io_req_task_submit (io_uring/io_uring.c:1511)&#x9; io_handle_tw_list (io_uring/io_uring.c:1198)&lt;snip&gt;Line numbers against commit 18daea77cca6 (&#34;Merge tag &#39;for-linus&#39; ofgit://git.kernel.org/pub/scm/virt/kvm/kvm&#34;).These races involve writes and reads to the same memory location bydifferent tasks running on different CPUs. To mitigate this, refactorthe code to use atomic operations such as set_bit(), test_bit(), andclear_bit() instead of basic &#34;and&#34; and &#34;or&#34; operations. This ensuresthread-safe manipulation of worker flags.Also, move `create_index` to avoid holes in the structure.(CVE-2024-39508)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 pagetable entry for deallocated pages to detect illegal memory accesses tofreed pages.This function set/clear the valid bit using __set_memory(). __set_memory()acquires init_mm&#39;s semaphore, and this operation may sleep. This isproblematic, 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:1578in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 2, name: kthreaddpreempt_count: 2, expected: 0CPU: 0 PID: 2 Comm: kthreadd Not tainted 6.9.0-g1d4c6d784ef6 #37Hardware 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/0x1cRewrite this function with apply_to_existing_page_range(). It is fine tonot have any locking, because __kernel_map_pages() works with pages beingallocated/deallocated and those pages are not changed by anyone else in themeantime.(CVE-2024-40915)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 anERR_PTR value in error cases. Existing drivers (idxd and uacce) onlycheck the return value with IS_ERR(). This could potentially lead toa kernel NULL pointer dereference issue if the function returns NULLinstead of an error pointer.In reality, this doesn&#39;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) willreturn an error, and the device drivers won&#39;t call iommu_sva_bind_device()at all.(CVE-2024-40945)In the Linux kernel, the following vulnerability has been resolved:ima: Avoid blocking in RCU read-side critical sectionA panic happens in ima_match_policy:BUG: unable to handle kernel NULL pointer dereference at 0000000000000010PGD 42f873067 P4D 0Oops: 0000 [#1] SMP NOPTICPU: 5 PID: 1286325 Comm: kubeletmonit.shKdump: loaded Tainted: PHardware name: QEMU Standard PC (i440FX + PIIX, 1996),               BIOS 0.0.0 02/06/2015RIP: 0010:ima_match_policy+0x84/0x450Code: 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 0fRSP: 0018:ff71570009e07a80 EFLAGS: 00010207RAX: 0000000000000000 RBX: 0000000000000000 RCX: 0000000000000200RDX: ffffffffad8dc7c0 RSI: 0000000024924925 RDI: ff3e27850dea2000RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffffabfce739R10: ff3e27810cc42400 R11: 0000000000000000 R12: ff3e2781825ef970R13: 00000000ff3e2785 R14: 000000000000000c R15: 0000000000000001FS:  00007f5195b51740(0000)GS:ff3e278b12d40000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000010 CR3: 0000000626d24002 CR4: 0000000000361ee0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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/0xcaCommit c7423dbdbc9e (&#34;ima: Handle -ESTALE returned byima_filter_rule_match()&#34;) introduced call to ima_lsm_copy_rule within aRCU read-side critical section which contains kmalloc with GFP_KERNEL.This implies a possible sleep and violates limitations of RCU read-sidecritical sections on non-PREEMPT systems.Sleeping within RCU read-side critical section might causesynchronize_rcu() returning early and break RCU protection, allowing aUAF to happen.The root cause of this issue could be described as follows:|&#x9;Thread A&#x9;|&#x9;Thread B&#x9;||&#x9;&#x9;&#x9;|ima_match_policy&#x9;||&#x9;&#x9;&#x9;|  rcu_read_lock&#x9;||ima_lsm_update_rule&#x9;|&#x9;&#x9;&#x9;||  synchronize_rcu&#x9;|&#x9;&#x9;&#x9;||&#x9;&#x9;&#x9;|    kmalloc(GFP_KERNEL)||&#x9;&#x9;&#x9;|      sleep&#x9;&#x9;|==&gt; synchronize_rcu returns early|  kfree(entry)&#x9;&#x9;|&#x9;&#x9;&#x9;||&#x9;&#x9;&#x9;|    entry = entry-&gt;next|==&gt; UAF happens and entry now becomes NULL (or could be anything).|&#x9;&#x9;&#x9;|    entry-&gt;action&#x9;|==&gt; Accessing entry might cause panic.To fix this issue, we are converting all kmalloc that is called withinRCU read-side critical section to use GFP_ATOMIC.[PM: fixed missing comment, long lines, !CONFIG_IMA_LSM_RULES case](CVE-2024-40947)In the Linux kernel, the following vulnerability has been resolved:dmaengine: idxd: Fix possible Use-After-Free in irq_process_work_listUse list_for_each_entry_safe() to allow iterating through the list anddeleting the entry in the iteration process. The descriptor is freed viaidxd_desc_complete() and there&#39;s a slight chance may cause issue forthe list iterator when the descriptor is reused by another threadwithout it being deleted from the list.(CVE-2024-40956)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 PTIKASAN: null-ptr-deref in range [0x0000000000000658-0x000000000000065f]CPU: 1 PID: 22444 Comm: syz-executor.0 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0Hardware 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:758Code: 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 19RSP: 0018:ffffc900034af070 EFLAGS: 00010203RAX: dffffc0000000000 RBX: 0000000000000000 RCX: ffffc90004521000RDX: 00000000000000cb RSI: ffffffff8990d0cd RDI: 000000000000065cRBP: ffffc900034af150 R08: 0000000000000005 R09: 0000000000000000R10: 0000000000000001 R11: 0000000000000002 R12: 000000000000000aR13: 1ffff92000695e18 R14: ffff8880244a1d20 R15: 0000000000000000FS:  00007f4844a5a6c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000001b31b27000 CR3: 000000002d42c000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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-40960)In the Linux kernel, the following vulnerability has been resolved:serial: imx: Introduce timeout when waiting on transmitter emptyBy waiting at most 1 second for USR2_TXDC to be set, we avoid a potentialdeadlock.In case of the timeout, there is not much we can do, so we simply ignorethe transmitter state and optimistically try to continue.(CVE-2024-40967)In the Linux kernel, the following vulnerability has been resolved:ext4: do not create EA inode under buffer lockext4_xattr_set_entry() creates new EA inodes while holding buffer lockon the external xattr block. This is problematic as it nests all theallocation locking (which acquires locks on other buffers) under thebuffer lock. This can even deadlock when the filesystem is corrupted ande.g. quota file is setup to contain xattr block as data block. Move theallocation of EA inode out of ext4_xattr_set_entry() into the callers.(CVE-2024-40972)In the Linux kernel, the following vulnerability has been resolved:drop_monitor: replace spin_lock by raw_spin_locktrace_drop_common() is called with preemption disabled, and it acquiresa spin_lock. This is problematic for RT kernels because spin_locks aresleeping locks in this configuration, which causes the following splat:BUG: sleeping function called from invalid context at kernel/locking/spinlock_rt.c:48in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 449, name: rcuc/47preempt_count: 1, expected: 0RCU nest depth: 2, expected: 25 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/0x290irq event stamp: 139909hardirqs last  enabled at (139908): [&lt;ffffffffb1df2b33&gt;] _raw_spin_unlock_irqrestore+0x63/0x80hardirqs last disabled at (139909): [&lt;ffffffffb19bd03d&gt;] trace_drop_common.constprop.0+0x26d/0x290softirqs last  enabled at (139892): [&lt;ffffffffb07a1083&gt;] __local_bh_enable_ip+0x103/0x170softirqs last disabled at (139898): [&lt;ffffffffb0909b33&gt;] rcu_cpu_kthread+0x93/0x1f0Preemption disabled at:[&lt;ffffffffb1de786b&gt;] rt_mutex_slowunlock+0xab/0x2e0CPU: 47 PID: 449 Comm: rcuc/47 Not tainted 6.9.0-rc2-rt1+ #7Hardware name: Dell Inc. PowerEdge R650/0Y2G81, BIOS 1.6.5 04/15/2022Call 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 issuebecause we could easily replace it with a local_lock.Replace the spin_lock with raw_spin_lock to avoid sleeping in atomiccontext.(CVE-2024-40980)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 inbatadv_purge_orig_ref() [1]Root cause is unknown, but we can avoid spending too muchtime 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:1271CPU: 0 PID: 621 Comm: kworker/u4:6 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024Workqueue: bat_events batadv_purge_origpstate: 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:386sp : ffff800099007970x29: ffff800099007980 x28: 1fffe00018fce1bd x27: dfff800000000000x26: ffff0000d2620008 x25: ffff0000c7e70de8 x24: 0000000000000001x23: 1fffe00018e57781 x22: dfff800000000000 x21: ffff80008aab71c4x20: ffff0001b40136c0 x19: ffff0000c72bbc08 x18: 1fffe0001a817bb0x17: ffff800125414000 x16: ffff80008032116c x15: 0000000000000001x14: 1fffe0001ee9d610 x13: 0000000000000000 x12: 0000000000000003x11: 0000000000000000 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 00000000005e5789 x7 : ffff80008aab61dc x6 : 0000000000000000x5 : 0000000000000000 x4 : 0000000000000001 x3 : 0000000000000000x2 : 0000000000000006 x1 : 0000000000000080 x0 : ffff800125414000Call 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:860Sending NMI from CPU 0 to CPUs 1:NMI backtrace for cpu 1CPU: 1 PID: 0 Comm: swapper/1 Not tainted 6.8.0-rc7-syzkaller-g707081b61156 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024pstate: 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:103sp : ffff800093a17d30x29: ffff800093a17d30 x28: dfff800000000000 x27: 1ffff00012742fb4x26: ffff80008ec9d000 x25: 0000000000000000 x24: 0000000000000002x23: 1ffff00011d93a74 x22: ffff80008ec9d3a0 x21: 0000000000000000x20: ffff0000c19dbc00 x19: ffff8000802d0fd8 x18: 1fffe00036804396x17: ffff80008ec9d000 x16: ffff8000802d089c x15: 0000000000000001---truncated---(CVE-2024-40981)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, thesecond request will block forever on the first request. This holdsrtnl_lock, and causes tasks to hang.Return -EAGAIN to prevent infinite looping, while keeping documentedbehavior.[1]INFO: task kworker/1:0:5088 blocked for more than 143 seconds.Not tainted 6.9.0-rc4-syzkaller-00173-g3cdb45594619 #0&#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.task:kworker/1:0 state:D stack:23744 pid:5088 tgid:5088 ppid:2 flags:0x00004000Workqueue: events_power_efficient reg_check_chans_workCall 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:6838schedule_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:752wiphy_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-40995)In the Linux kernel, the following vulnerability has been resolved:drm/amdkfd: don&#39;t allow mapping the MMIO HDP page with large pagesWe don&#39;t get the right offset in that case.  The GPU hasan unused 4K area of the register BAR space into which you canremap registers.  We remap the HDP flush registers into thisspace to allow userspace (CPU or GPU) to flush the HDP when itupdates VRAM.  However, on systems with &gt;4K pages, we end upexposing PAGE_SIZE of MMIO space.(CVE-2024-41011)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-perf" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.87.0.168.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.87.0.168.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.87.0.168.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1945</id>
          <title>An update for python-urllib3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-02"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-37891" id="CVE-2024-37891" title="CVE-2024-37891" type="cve"></reference>
          </references>
          <description> urllib3 is a user-friendly HTTP client library for Python. When using urllib3&#39;s proxy support with `ProxyManager`, the `Proxy-Authorization` header is only sent to the configured proxy, as expected. However, when sending HTTP requests *without* using urllib3&#39;s proxy support, it&#39;s possible to accidentally configure the `Proxy-Authorization` header even though it won&#39;t have any effect as the request is not using a forwarding proxy or a tunneling proxy. In those cases, urllib3 doesn&#39;t treat the `Proxy-Authorization` HTTP header as one carrying authentication material and thus doesn&#39;t strip the header on cross-origin redirects. Because this is a highly unlikely scenario, we believe the severity of this vulnerability is low for almost all users. Out of an abundance of caution urllib3 will automatically strip the `Proxy-Authorization` header during cross-origin redirects to avoid the small chance that users are doing this on accident. Users should use urllib3&#39;s proxy support or disable automatic redirects to achieve safe processing of the `Proxy-Authorization` header, but we still decided to strip the header by default in order to further protect users who aren&#39;t using the correct approach. We believe the number of usages affected by this advisory is low. It requires all of the following to be true to be exploited: 1. Setting the `Proxy-Authorization` header without using urllib3&#39;s built-in proxy support. 2. Not disabling HTTP redirects. 3. Either not using an HTTPS origin server or for the proxy or target origin to redirect to a malicious origin. Users are advised to update to either version 1.26.19 or version 2.2.2. Users unable to upgrade may use the `Proxy-Authorization` header with urllib3&#39;s `ProxyManager`, disable HTTP redirects using `redirects=False` when sending requests, or not user the `Proxy-Authorization` header as mitigations.(CVE-2024-37891)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-urllib3" release="7.oe2203sp1" version="1.26.12">
                         <filename>python3-urllib3-1.26.12-7.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1951</id>
          <title>An update for openjdk-17 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"></reference>
          </references>
          <description>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-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 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-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 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-21140)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-21145)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).(CVE-2024-21147)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="java-17-openjdk" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-debuginfo" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-debuginfo-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-debugsource" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-debugsource-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-demo" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-demo-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-demo-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-devel" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-devel-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-devel-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-headless" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-headless-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-headless-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-javadoc" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-javadoc-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-javadoc-zip" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-jmods" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-jmods-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-jmods-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-slowdebug-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-src" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-src-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-17-openjdk-src-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-debuginfo" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-debuginfo-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-debugsource" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-debugsource-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-demo" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-demo-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-demo-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-demo-slowdebug-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-devel" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-devel-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-devel-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-devel-slowdebug-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-headless" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-headless-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-headless-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-headless-slowdebug-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-javadoc" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-javadoc-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-javadoc-zip" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-javadoc-zip-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-jmods" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-jmods-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-jmods-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-jmods-slowdebug-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-slowdebug-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-src" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-src-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-17-openjdk-src-slowdebug" release="0.oe2203sp1" version="17.0.12.7">
                         <filename>java-17-openjdk-src-slowdebug-17.0.12.7-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1958</id>
          <title>An update for openjdk-1.8.0 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21131" id="CVE-2024-21131" title="CVE-2024-21131" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21138" id="CVE-2024-21138" title="CVE-2024-21138" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21140" id="CVE-2024-21140" title="CVE-2024-21140" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21144" id="CVE-2024-21144" title="CVE-2024-21144" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21145" id="CVE-2024-21145" title="CVE-2024-21145" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21147" id="CVE-2024-21147" title="CVE-2024-21147" type="cve"></reference>
          </references>
          <description>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-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 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-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 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-21140)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-21144)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-21145)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).(CVE-2024-21147)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="java-1.8.0-openjdk" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-src" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="java-1.8.0-openjdk-javadoc" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-javadoc-1.8.0.422.b05-0.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="java-1.8.0-openjdk-javadoc-zip" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-javadoc-zip-1.8.0.422.b05-0.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-accessibility" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-accessibility-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-accessibility-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-accessibility-slowdebug-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-debuginfo" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-debuginfo-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-debugsource" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-debugsource-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-demo" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-demo-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-demo-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-demo-slowdebug-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-devel" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-devel-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-devel-slowdebug-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-headless" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-headless-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-headless-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-headless-slowdebug-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-openjfx" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-openjfx-devel-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-devel-slowdebug-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-openjfx-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-openjfx-slowdebug-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-slowdebug-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-src" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-src-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="java-1.8.0-openjdk-src-slowdebug" release="0.oe2203sp1" version="1.8.0.422.b05">
                         <filename>java-1.8.0-openjdk-src-slowdebug-1.8.0.422.b05-0.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1959</id>
          <title>An update for docker is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41110" id="CVE-2024-41110" title="CVE-2024-41110" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-41110)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="docker-engine" release="340.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-340.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="docker-engine-debuginfo" release="340.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-340.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="docker-engine-debugsource" release="340.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-340.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="docker-engine" release="340.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-18.09.0-340.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="docker-engine-debuginfo" release="340.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debuginfo-18.09.0-340.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="docker-engine-debugsource" release="340.oe2203sp1" version="18.09.0">
                         <filename>docker-engine-debugsource-18.09.0-340.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1964</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47382" id="CVE-2021-47382" title="CVE-2021-47382" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52674" id="CVE-2023-52674" title="CVE-2023-52674" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52764" id="CVE-2023-52764" title="CVE-2023-52764" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52887" id="CVE-2023-52887" title="CVE-2023-52887" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33621" id="CVE-2024-33621" title="CVE-2024-33621" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-35904" id="CVE-2024-35904" title="CVE-2024-35904" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38546" id="CVE-2024-38546" title="CVE-2024-38546" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38561" id="CVE-2024-38561" title="CVE-2024-38561" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38594" id="CVE-2024-38594" title="CVE-2024-38594" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38627" id="CVE-2024-38627" title="CVE-2024-38627" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39471" id="CVE-2024-39471" title="CVE-2024-39471" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39497" id="CVE-2024-39497" title="CVE-2024-39497" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40910" id="CVE-2024-40910" title="CVE-2024-40910" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40953" id="CVE-2024-40953" title="CVE-2024-40953" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40959" id="CVE-2024-40959" title="CVE-2024-40959" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40961" id="CVE-2024-40961" title="CVE-2024-40961" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40976" id="CVE-2024-40976" title="CVE-2024-40976" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40982" id="CVE-2024-40982" title="CVE-2024-40982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40988" id="CVE-2024-40988" title="CVE-2024-40988" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40999" id="CVE-2024-40999" title="CVE-2024-40999" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41013" id="CVE-2024-41013" title="CVE-2024-41013" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41014" id="CVE-2024-41014" title="CVE-2024-41014" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41019" id="CVE-2024-41019" title="CVE-2024-41019" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41020" id="CVE-2024-41020" title="CVE-2024-41020" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41022" id="CVE-2024-41022" title="CVE-2024-41022" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41023" id="CVE-2024-41023" title="CVE-2024-41023" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41027" id="CVE-2024-41027" title="CVE-2024-41027" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41040" id="CVE-2024-41040" title="CVE-2024-41040" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41041" id="CVE-2024-41041" title="CVE-2024-41041" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41044" id="CVE-2024-41044" title="CVE-2024-41044" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41048" id="CVE-2024-41048" title="CVE-2024-41048" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41062" id="CVE-2024-41062" title="CVE-2024-41062" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41063" id="CVE-2024-41063" title="CVE-2024-41063" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41064" id="CVE-2024-41064" title="CVE-2024-41064" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41069" id="CVE-2024-41069" title="CVE-2024-41069" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41070" id="CVE-2024-41070" title="CVE-2024-41070" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41072" id="CVE-2024-41072" title="CVE-2024-41072" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41077" id="CVE-2024-41077" title="CVE-2024-41077" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41079" id="CVE-2024-41079" title="CVE-2024-41079" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41080" id="CVE-2024-41080" title="CVE-2024-41080" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41081" id="CVE-2024-41081" title="CVE-2024-41081" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41089" id="CVE-2024-41089" title="CVE-2024-41089" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41090" id="CVE-2024-41090" title="CVE-2024-41090" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41091" id="CVE-2024-41091" title="CVE-2024-41091" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41097" id="CVE-2024-41097" title="CVE-2024-41097" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42068" id="CVE-2024-42068" title="CVE-2024-42068" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42076" id="CVE-2024-42076" title="CVE-2024-42076" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42077" id="CVE-2024-42077" title="CVE-2024-42077" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42080" id="CVE-2024-42080" title="CVE-2024-42080" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42082" id="CVE-2024-42082" title="CVE-2024-42082" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42084" id="CVE-2024-42084" title="CVE-2024-42084" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42086" id="CVE-2024-42086" title="CVE-2024-42086" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42089" id="CVE-2024-42089" title="CVE-2024-42089" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42090" id="CVE-2024-42090" title="CVE-2024-42090" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42092" id="CVE-2024-42092" title="CVE-2024-42092" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42093" id="CVE-2024-42093" title="CVE-2024-42093" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42094" id="CVE-2024-42094" title="CVE-2024-42094" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42097" id="CVE-2024-42097" title="CVE-2024-42097" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42101" id="CVE-2024-42101" title="CVE-2024-42101" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42106" id="CVE-2024-42106" title="CVE-2024-42106" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42115" id="CVE-2024-42115" title="CVE-2024-42115" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42124" id="CVE-2024-42124" title="CVE-2024-42124" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42129" id="CVE-2024-42129" title="CVE-2024-42129" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42145" id="CVE-2024-42145" title="CVE-2024-42145" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42155" id="CVE-2024-42155" title="CVE-2024-42155" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42160" id="CVE-2024-42160" title="CVE-2024-42160" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42161" id="CVE-2024-42161" title="CVE-2024-42161" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42162" id="CVE-2024-42162" title="CVE-2024-42162" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42224" id="CVE-2024-42224" title="CVE-2024-42224" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42228" id="CVE-2024-42228" title="CVE-2024-42228" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:s390/qeth: fix deadlock during failing recoveryCommit 0b9902c1fcc5 (&#34;s390/qeth: fix deadlock during recovery&#34;) removedtaking discipline_mutex inside qeth_do_reset(), fixing potentialdeadlocks. An error path was missed though, that still takesdiscipline_mutex and thus has the original deadlock potential.Intermittent deadlocks were seen when a qeth channel path is configuredoffline, causing a race between qeth_do_reset and ccwgroup_remove.Call qeth_set_offline() directly in the qeth_do_reset() error case andthen a new variant of ccwgroup_set_offline(), without takingdiscipline_mutex.(CVE-2021-47382)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 andSCARLETT2_MIXER_MAX_VALUE so we don&#39;t attempt to access outsidescarlett2_mixer_values[].(CVE-2023-52674)In the Linux kernel, the following vulnerability has been resolved:media: gspca: cpia1: shift-out-of-bounds in set_flickerSyzkaller reported the following issue:UBSAN: shift-out-of-bounds in drivers/media/usb/gspca/cpia1.c:1031:27shift exponent 245 is too large for 32-bit type &#39;int&#39;When the value of the variable &#34;sd-&gt;params.exposure.gain&#34; exceeds thenumber of bits in an integer, a shift-out-of-bounds error is reported. Itis triggered because the variable &#34;currentexp&#34; cannot be left-shifted bymore than the number of bits in an integer. In order to avoid invalidrange during left-shift, the conditional expression is added.(CVE-2023-52764)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_newThis patch enhances error handling in scenarios with RTS (Request toSend) messages arriving closely. It replaces the less informative WARN_ON_ONCEbacktraces with a new error handling method. This provides clearer errormessages 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&#x9;# send first RTS&#x9;cansend vcan0 18EC8090#1014000303002301;&#x9;# send second RTS&#x9;cansend vcan0 18EC8090#1014000303002301;&#x9;# send abort&#x9;cansend vcan0 18EC8090#ff00000000002301;done(CVE-2023-52887)In the Linux kernel, the following vulnerability has been resolved:ipvlan: Dont Use skb-&gt;sk in ipvlan_process_v{4,6}_outboundRaw packet from PF_PACKET socket ontop of an IPv6-backed ipvlan device willhit WARN_ON_ONCE() in sk_mc_loop() through sch_direct_xmit() path.WARNING: CPU: 2 PID: 0 at net/core/sock.c:775 sk_mc_loop+0x2d/0x70Modules linked in: sch_netem ipvlan rfkill cirrus drm_shmem_helper sg drm_kms_helperCPU: 2 PID: 0 Comm: swapper/2 Kdump: loaded Not tainted 6.9.0+ #279Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.15.0-1 04/01/2014RIP: 0010:sk_mc_loop+0x2d/0x70Code: fa 0f 1f 44 00 00 65 0f b7 15 f7 96 a3 4f 31 c0 66 85 d2 75 26 48 85 ff 74 1cRSP: 0018:ffffa9584015cd78 EFLAGS: 00010212RAX: 0000000000000011 RBX: ffff91e585793e00 RCX: 0000000002c6a001RDX: 0000000000000000 RSI: 0000000000000040 RDI: ffff91e589c0f000RBP: ffff91e5855bd100 R08: 0000000000000000 R09: 3d00545216f43d00R10: ffff91e584fdcc50 R11: 00000060dd8616f4 R12: ffff91e58132d000R13: ffff91e584fdcc68 R14: ffff91e5869ce800 R15: ffff91e589c0f000FS:  0000000000000000(0000) GS:ffff91e898100000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f788f7c44c0 CR3: 0000000008e1a000 CR4: 00000000000006f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace:&lt;IRQ&gt; ? __warn (kernel/panic.c:693) ? sk_mc_loop (net/core/sock.c:760) ? report_bug (lib/bug.c:201 lib/bug.c:219) ? handle_bug (arch/x86/kernel/traps.c:239) ? exc_invalid_op (arch/x86/kernel/traps.c:260 (discriminator 1)) ? asm_exc_invalid_op (./arch/x86/include/asm/idtentry.h:621) ? sk_mc_loop (net/core/sock.c:760) ip6_finish_output2 (net/ipv6/ip6_output.c:83 (discriminator 1)) ? nf_hook_slow (net/netfilter/core.c:626) ip6_finish_output (net/ipv6/ip6_output.c:222) ? __pfx_ip6_finish_output (net/ipv6/ip6_output.c:215) ipvlan_xmit_mode_l3 (drivers/net/ipvlan/ipvlan_core.c:602) ipvlan ipvlan_start_xmit (drivers/net/ipvlan/ipvlan_main.c:226) ipvlan dev_hard_start_xmit (net/core/dev.c:3594) sch_direct_xmit (net/sched/sch_generic.c:343) __qdisc_run (net/sched/sch_generic.c:416) net_tx_action (net/core/dev.c:5286) handle_softirqs (kernel/softirq.c:555) __irq_exit_rcu (kernel/softirq.c:589) sysvec_apic_timer_interrupt (arch/x86/kernel/apic/apic.c:1043)The warning triggers as this:packet_sendmsg   packet_snd //skb-&gt;sk is packet sk      __dev_queue_xmit         __dev_xmit_skb //q-&gt;enqueue is not NULL             __qdisc_run               sch_direct_xmit                 dev_hard_start_xmit                   ipvlan_start_xmit                      ipvlan_xmit_mode_l3 //l3 mode                        ipvlan_process_outbound //vepa flag                          ipvlan_process_v6_outbound                            ip6_local_out                                __ip6_finish_output                                  ip6_finish_output2 //multicast packet                                    sk_mc_loop //sk-&gt;sk_family is AF_PACKETCall ip{6}_local_out() with NULL sk in ipvlan as other tunnels to fix this.(CVE-2024-33621)In the Linux kernel, the following vulnerability has been resolved:selinux: avoid dereference of garbage after mount failureIn case kern_mount() fails and returns an error pointer return in theerror branch instead of continuing and dereferencing the error pointer.While on it drop the never read static variable selinuxfs_mount.(CVE-2024-35904)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-38546)In the Linux kernel, the following vulnerability has been resolved:kunit: Fix kthread referenceThere is a race condition when a kthread finishes after the deadline andbefore the call to kthread_stop(), which may lead to use after free.(CVE-2024-38561)In the Linux kernel, the following vulnerability has been resolved:net: stmmac: move the EST lock to struct stmmac_privReinitialize the whole EST structure would also reset the mutexlock which is embedded in the EST structure, and then triggerthe following warning. To address this, move the lock to structstmmac_priv. We also need to reacquire the mutex lock when doingthis initialization.DEBUG_LOCKS_WARN_ON(lock-&gt;magic != lock)WARNING: CPU: 3 PID: 505 at kernel/locking/mutex.c:587 __mutex_lock+0xd84/0x1068 Modules linked in: CPU: 3 PID: 505 Comm: tc Not tainted 6.9.0-rc6-00053-g0106679839f7-dirty #29 Hardware name: NXP i.MX8MPlus EVK board (DT) pstate: 60000005 (nZCv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--) pc : __mutex_lock+0xd84/0x1068 lr : __mutex_lock+0xd84/0x1068 sp : ffffffc0864e3570 x29: ffffffc0864e3570 x28: ffffffc0817bdc78 x27: 0000000000000003 x26: ffffff80c54f1808 x25: ffffff80c9164080 x24: ffffffc080d723ac x23: 0000000000000000 x22: 0000000000000002 x21: 0000000000000000 x20: 0000000000000000 x19: ffffffc083bc3000 x18: ffffffffffffffff x17: ffffffc08117b080 x16: 0000000000000002 x15: ffffff80d2d40000 x14: 00000000000002da x13: ffffff80d2d404b8 x12: ffffffc082b5a5c8 x11: ffffffc082bca680 x10: ffffffc082bb2640 x9 : ffffffc082bb2698 x8 : 0000000000017fe8 x7 : c0000000ffffefff x6 : 0000000000000001 x5 : ffffff8178fe0d48 x4 : 0000000000000000 x3 : 0000000000000027 x2 : ffffff8178fe0d50 x1 : 0000000000000000 x0 : 0000000000000000 Call trace:  __mutex_lock+0xd84/0x1068  mutex_lock_nested+0x28/0x34  tc_setup_taprio+0x118/0x68c  stmmac_setup_tc+0x50/0xf0  taprio_change+0x868/0xc9c(CVE-2024-38594)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() whichfrees &#34;stm&#34; so the vfree(stm) on the next line is a double free.(CVE-2024-38627)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: add error handle to avoid out-of-boundsif the sdma_v4_0_irq_id_to_seq return -EINVAL, the process shouldbe stop to avoid out-of-bounds read, so directly return -EINVAL.(CVE-2024-39471)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_mmapallows users to call mmap with PROT_WRITE and MAP_PRIVATE flagcausing 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-39497)In the Linux kernel, the following vulnerability has been resolved:ax25: Fix refcount imbalance on inbound connectionsWhen releasing a socket in ax25_release(), we call netdev_put() todecrease the refcount on the associated ax.25 device. However, theexecution path for accepting an incoming connection never callsnetdev_hold(). This imbalance leads to refcount errors, and ultimatelyto kernel crashes.A typical call trace for the above situation will start with one of thefollowing 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 getsstuck in an infinite loop:    unregister_netdevice: waiting for ax0 to become free. Usage count = 0This patch corrects these issues by ensuring that we call netdev_hold()and ax25_dev_hold() for new connections in ax25_accept(). This makes thelogic leading to ax25_accept() match the logic for ax25_bind(): in bothcases we increment the refcount, which is ultimately decremented inax25_release().(CVE-2024-40910)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 theloads and stores are atomic.  In the extremely unlikely scenario thecompiler tears the stores, it&#39;s theoretically possible for KVM to attemptto get a vCPU using an out-of-bounds index, e.g. if the write is splitinto multiple 8-bit stores, and is paired with a 32-bit load on a VM with257 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:?&#x9;&#x9; 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:?&#x9;&#x9;&#x9;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-2024-40953)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 PTIKASAN: null-ptr-deref in range [0x0000000000000000-0x0000000000000007]CPU: 1 PID: 12 Comm: kworker/u8:1 Not tainted 6.10.0-rc2-syzkaller-00383-gb8481381d4e2 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024Workqueue: wg-kex-wg1 wg_packet_handshake_send_worker RIP: 0010:xfrm6_get_saddr+0x93/0x130 net/ipv6/xfrm6_policy.c:64Code: 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 00RSP: 0018:ffffc90000117378 EFLAGS: 00010246RAX: dffffc0000000000 RBX: ffff88807b079dc0 RCX: ffffffff89a0d6d7RDX: 0000000000000000 RSI: ffffffff89a0d6e9 RDI: ffff88807b079e98RBP: ffff88807ad73248 R08: 0000000000000007 R09: fffffffffffff000R10: ffff88807b079dc0 R11: 0000000000000007 R12: ffffc90000117480R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS:  0000000000000000(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4586d00440 CR3: 0000000079042000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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-40959)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 NULLOops: general protection fault, probably for non-canonical address 0xdffffc00000000bc: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x00000000000005e0-0x00000000000005e7]CPU: 0 PID: 11237 Comm: syz-executor.3 Not tainted 6.10.0-rc2-syzkaller-00249-gbe27b8965297 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024 RIP: 0010:fib6_nh_init+0x640/0x2160 net/ipv6/route.c:3606Code: 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 8bRSP: 0018:ffffc900032775a0 EFLAGS: 00010202RAX: 00000000000000bc RBX: 00000000000005e0 RCX: 0000000000000000RDX: 0000000000000010 RSI: ffffc90003277a54 RDI: ffff88802b3a08d8RBP: ffffc900032778b0 R08: 00000000000002fc R09: 0000000000000000R10: 00000000000002fc R11: 0000000000000000 R12: ffff88802b3a08b8R13: 1ffff9200064eec8 R14: ffffc90003277a00 R15: dffffc0000000000FS:  00007f940feb06c0(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000000 CR3: 00000000245e8000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call 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/0x7fRIP: 0033:0x7f940f07cea9(CVE-2024-40961)In the Linux kernel, the following vulnerability has been resolved:drm/lima: mask irqs in timeout path before hard resetThere is a race condition in which a rendering job might take just longenough to trigger the drm sched job timeout handler but also stillcomplete 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 refcountimbalance 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/0xc0We can prevent that race condition entirely by masking the irqs at thebeginning of the timeout handler, at which point we give up on waitingfor that job entirely.The irqs will be enabled again at the next hard reset which is alreadydone as a recovery by the timeout handler.(CVE-2024-40976)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 &#39;dev&#39; pointerto &#39;struct ssb_device *&#39;. However, it mistakenly dereferences &#39;dev&#39; beforeperforming the NULL check, potentially leading to a NULL pointerdereference if &#39;dev&#39; is NULL.To fix this issue, move the NULL check before dereferencing the &#39;dev&#39; pointer,ensuring that the pointer is valid before attempting to use it.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-40982)In the Linux kernel, the following vulnerability has been resolved:drm/radeon: fix UBSAN warning in kv_dpm.cAdds bounds check for sumo_vid_mapping_entry.(CVE-2024-40988)In the Linux kernel, the following vulnerability has been resolved:net: ena: Add validation for completion descriptors consistencyValidate that `first` flag is set only for the firstdescriptor 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-40999)In the Linux kernel, the following vulnerability has been resolved:xfs: don&#39;t walk off the end of a directory data blockThis adds sanity checks for xfs_dir2_data_unused and xfs_dir2_data_entryto make sure don&#39;t stray beyond valid memory region. Before patching, theloop simply checks that the start offset of the dup and dep is within therange. So in a crafted image, if last entry is xfs_dir2_data_unused, wecan change dup-&gt;length to dup-&gt;length-1 and leave 1 byte of space. In thenext traversal, this space will be considered as dup or dep. We mayencounter an out of bound read when accessing the fixed members.In the patch, we make sure that the remaining bytes large enough to holdan unused entry before accessing xfs_dir2_data_unused andxfs_dir2_data_unused is XFS_DIR2_DATA_ALIGN byte aligned. We also makesure that the remaining bytes large enough to hold a dirent with asingle-byte name before accessing xfs_dir2_data_entry.(CVE-2024-41013)In the Linux kernel, the following vulnerability has been resolved:xfs: add bounds checking to xlog_recover_process_dataThere is a lack of verification of the space occupied by fixed membersof xlog_op_header in the xlog_recover_process_data.We can create a crafted image to trigger an out of bounds read byfollowing 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_crcFix:Add a check to make sure there is sufficient space to access fixed membersof xlog_op_header.(CVE-2024-41014)In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Validate ff offsetThis adds sanity checks for ff offset. There is a checkon rt-&gt;first_free at first, but walking through by ffwithout any check. If the second ff is a large offset.We may encounter an out-of-bound read.(CVE-2024-41019)In the Linux kernel, the following vulnerability has been resolved:filelock: Fix fcntl/close race recovery compat pathWhen I wrote commit 3cad1bc01041 (&#34;filelock: Remove locks reliably whenfcntl/close race is detected&#34;), I missed that there are two copies of thecode I was patching: The normal version, and the version for 64-bit offsetson 32-bit kernels.Thanks to Greg KH for stumbling over this while doing the stablebackport...Apply exactly the same fix to the compat path for 32-bit kernels.(CVE-2024-41020)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix signedness bug in sdma_v4_0_process_trap_irq()The &#34;instance&#34; variable needs to be signed for the error handling to work.(CVE-2024-41022)In the Linux kernel, the following vulnerability has been resolved:sched/deadline: Fix task_struct reference leakDuring the execution of the following stress test with linux-rt:stress-ng --cyclic 30 --timeout 30 --minimize --quietkmemleak frequently reported a memory leak concerning the task_struct:unreferenced object 0xffff8881305b8000 (size 16136):  comm &#34;stress-ng&#34;, 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/0x76The issue occurs in start_dl_timer(), which increments the task_structreference 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_structreference count is properly decremented when the timer is canceled.(CVE-2024-41023)In the Linux kernel, the following vulnerability has been resolved:Fix userfaultfd_api to return EINVAL as expectedCurrently if we request a feature that is not set in the Kernel config wefail silently and return all the available features.  However, the manpage indicates we should return an EINVAL.We need to fix this issue since we can end up with a Kernel warning shoulda program request the feature UFFD_FEATURE_WP_UNPOPULATED on a kernel withthe 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-2024-41027)In the Linux kernel, the following vulnerability has been resolved:net/sched: Fix UAF when resolving a clashKASAN 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/0x491The ct may be dropped if a clash has been resolved but is still passed tothe tcf_ct_flow_table_process_conn function for further usage. This issuecan be fixed by retrieving ct from skb again after confirming conntrack.(CVE-2024-41040)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 refcountof the looked-up sk and use sock_pfree() as skb-&gt;destructor, so we checkSOCK_RCU_FREE to ensure that the sk is safe to access during the RCU graceperiod.Currently, SOCK_RCU_FREE is flagged for a bound socket after being putinto the hash table.  Moreover, the SOCK_RCU_FREE check is done too earlyin udp_v[46]_early_demux() and sk_lookup(), so there could be a small racewindow:  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 (&#34;net:set SOCK_RCU_FREE before inserting socket into hashtable&#34;).Let&#39;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:2599Modules linked in:CPU: 0 PID: 11198 Comm: syz-executor.1 Not tainted 6.9.0-g93bda33046e7 #13Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.0-0-gd239552ce722-prebuilt.qemu.org 04/01/2014RIP: 0010:udp_v4_early_demux+0x481/0xb70 net/ipv4/udp.c:2599Code: 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 52RSP: 0018:ffffc9000ce3fa58 EFLAGS: 00010293RAX: 0000000000000000 RBX: 0000000000000000 RCX: ffffffff8318c92cRDX: ffff888036ccde00 RSI: ffffffff8318c2f1 RDI: 0000000000000001RBP: ffff88805a2dd6e0 R08: 0000000000000001 R09: 0000000000000000R10: 0000000000000000 R11: 0001ffffffffffff R12: ffff88805a2dd680R13: 0000000000000007 R14: ffff88800923f900 R15: ffff88805456004eFS:  00007fc449127640(0000) GS:ffff88807dc00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fc449126e38 CR3: 000000003de4b002 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000600PKRU: 55555554Call 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/0x53RIP: 0033:0x7fc44a68bc1fCode: 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 48RSP: 002b:00007fc449126c90 EFLAGS: 00000293 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00000000004bc050 RCX: 00007fc44a68bc1fR---truncated---(CVE-2024-41041)In the Linux kernel, the following vulnerability has been resolved:ppp: reject claimed-as-LCP but actually malformed packetsSince &#39;ppp_async_encode()&#39; assumes valid LCP packets (with codefrom 1 to 7 inclusive), add &#39;ppp_check_packet()&#39; to ensure thatLCP packet has an actual body beyond PPP_LCP header bytes, andreject claimed-as-LCP but actually malformed data otherwise.(CVE-2024-41044)In the Linux kernel, the following vulnerability has been resolved:skmsg: Skip zero length skb in sk_msg_recvmsgWhen running BPF selftests (./test_progs -t sockmap_basic) on a Loongarchplatform, 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_shutdownsubtest in sockmap_basic.This crash is because a NULL pointer is passed to page_address() in thesk_msg_recvmsg(). Due to the different implementations depending on thearchitecture, page_address(NULL) will trigger a panic on Loongarchplatform but not on x86 platform. So this bug was hidden on x86 platformfor a while, but now it is exposed on Loongarch platform. The root causeis 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():&#x9;shutdown(p1, SHUT_WR);In this case, in sk_psock_skb_ingress_enqueue(), num_sge is zero, and nopage is put to this sge (see sg_set_page in sg_set_page), but this emptysge is queued into ingress_msg list.And in sk_msg_recvmsg(), this empty sge is used, and a NULL page is got bysg_page(sge). Pass this NULL page to copy_page_to_iter(), which passes itto 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&#39;s a zero length skb, skip invokingcopy_page_to_iter(). We are using the EFAULT return triggered bycopy_page_to_iter to check for is_fin in tcp_bpf.c.(CVE-2024-41048)In the Linux kernel, the following vulnerability has been resolved:bluetooth/l2cap: sync sock recv cb and releaseThe 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&#x9;   l2cap_sock_release         hci_acldata_packet&#x9;   l2cap_sock_kill            l2cap_recv_frame&#x9;   sk_free                    l2cap_conless_channel&#x9;                              l2cap_sock_recv_cbIf hci_rx_work processes the data that needs to be received before the sock isclosed, then everything is normal; Otherwise, the work thread may access thereleased sock when receiving data.Add a chan mutex in the rx callback of the sock to achieve synchronization betweenthe sock release and recv cb.Sock is dead, so set chan data to NULL, avoid others use invalid sock pointer.(CVE-2024-41062)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 atdestroy_workqueue(), for hci_error_reset() is called fromhdev-&gt;req_workqueue which destroy_workqueue() needs to flush.We need to make sure that hdev-&gt;{rx_work,cmd_work,tx_work} which arequeued into hdev-&gt;workqueue and hdev-&gt;{power_on,error_reset} which arequeued 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-41063)In the Linux kernel, the following vulnerability has been resolved:powerpc/eeh: avoid possible crash when edev-&gt;pdev changesIf a PCI device is removed during eeh_pe_report_edev(), edev-&gt;pdevwill change and can cause a crash, hold the PCI rescan/remove lockwhile taking a copy of edev-&gt;pdev-&gt;bus.(CVE-2024-41064)In the Linux kernel, the following vulnerability has been resolved:ASoC: topology: Fix references to freed memoryMost users after parsing a topology file, release memory used by it, sohaving pointer references directly into topology file contents is wrong.Use devm_kmemdup(), to allocate memory as needed.(CVE-2024-41069)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 doingfdput() on the returned fd. After the fdput() the tablefd is free to beclosed by another thread. The close calls kvm_spapr_tce_release() andthen release_spapr_tce_table() (via call_rcu()) which frees `stt`.Although there are calls to rcu_read_lock() inkvm_spapr_tce_attach_iommu_group() they are not sufficient to preventthe UAF, because `stt` is used outside the locked regions.With an artifcial delay after the fdput() and a userspace program whichtriggers 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/0x14Fix it by delaying the fdput() until `stt` is no longer in use, whichis effectively the entire function. To keep the patch minimal add a callto fdput() at each of the existing return paths. Future work can convertthe function to goto or __cleanup style cleanup.With the fix in place the test case no longer triggers the UAF.(CVE-2024-41070)In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: wext: add extra SIOCSIWSCAN data checkIn &#39;cfg80211_wext_siwscan()&#39;, add extra check whether number ofchannels passed via &#39;ioctl(sock, SIOCSIWSCAN, ...)&#39; doesn&#39;t exceedIW_MAX_FREQUENCIES and reject invalid request with -EINVAL otherwise.(CVE-2024-41072)In the Linux kernel, the following vulnerability has been resolved:null_blk: fix validation of block sizeBlock size should be between 512 and PAGE_SIZE and be a power of 2. The currentcheck does not validate this, so update the check.Without this patch, null_blk would Oops due to a null pointer deref whenloaded with bs=1536 [1].[axboe: remove unnecessary braces and != 0 check](CVE-2024-41077)In the Linux kernel, the following vulnerability has been resolved:nvmet: always initialize cqe.resultThe spec doesn&#39;t mandate that the first two double words (aka results)for the command queue entry need to be set to 0 when they are notused (not specified). Though, the target implemention returns 0 for TCPand FC but not for RDMA.Let&#39;s make RDMA behave the same and thus explicitly initializing theresult field. This prevents leaking any data from the stack.(CVE-2024-41079)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 (&#34;io_uring: drop ctx-&gt;uring_lockbefore acquiring sqd-&gt;lock&#34;), this can lead to a potential deadlocksituation.To resolve this issue, the uring_lock is released before callingio_put_sq_data(), and then it is re-acquired after the function call.This change ensures that the locks are acquired in the correctorder, preventing the possibility of a deadlock.(CVE-2024-41080)In the Linux kernel, the following vulnerability has been resolved:ila: block BH in ila_output()As explained in commit 1378817486d6 (&#34;tipc: block BHbefore using dst_cache&#34;), net/core/dst_cache.chelpers 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-41081)In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_hd_modesIn nv17_tv_get_hd_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). The same applies to drm_cvt_mode().Add a check to avoid null pointer dereference.(CVE-2024-41089)In the Linux kernel, the following vulnerability has been resolved:tap: add missing verification for short frameThe cited commit missed to check against the validity of the frame lengthin the tap_get_user_xdp() path, which could cause a corrupted skb to besent downstack. Even before the skb is transmitted, thetap_get_user_xdp()--&gt;skb_set_network_header() may assume the size is morethan ETH_HLEN. Once transmitted, this could either cause out-of-boundaccess beyond the actual length, or confuse the underlayer with incorrector inconsistent header length in the skb metadata.In the alternative path, tap_get_user() already prohibits short frame whichhas the length less than Ethernet header size from being transmitted.This is to drop any frame shorter than the Ethernet header size just likehow tap_get_user() does.CVE: CVE-2024-41090(CVE-2024-41090)In the Linux kernel, the following vulnerability has been resolved:tun: add missing verification for short frameThe cited commit missed to check against the validity of the frame lengthin the tun_xdp_one() path, which could cause a corrupted skb to be sentdownstack. Even before the skb is transmitted, thetun_xdp_one--&gt;eth_type_trans() may access the Ethernet header although itcan be less than ETH_HLEN. Once transmitted, this could either causeout-of-bound access beyond the actual length, or confuse the underlayerwith incorrect or inconsistent header length in the skb metadata.In the alternative path, tun_get_user() already prohibits short frame whichhas the length less than Ethernet header size from being transmitted forIFF_TAP.This is to drop any frame shorter than the Ethernet header size just likehow tun_get_user() does.CVE: CVE-2024-41091(CVE-2024-41091)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 toincomplete checking of present usb endpoints. As such, wrongendpoints types may be used at urb sumbitting stage which in turntriggers a warning in usb_submit_urb().Fix the issue by verifying that required endpoint types are presentfor 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 3WARNING: CPU: 0 PID: 8667 at drivers/usb/core/urb.c:502 usb_submit_urb+0xed2/0x18a0 drivers/usb/core/urb.c:502Modules linked in:CPU: 0 PID: 8667 Comm: kworker/0:4 Not tainted 5.14.0-rc4-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Workqueue: usb_hub_wq hub_eventRIP: 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-41097)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-42068)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&#39;t initializeit. This causes the kernel-infoleak issue. Fix this by initializingunused 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/0x7fUninit 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/0x7fBytes 12-15 of 16 are uninitializedMemory access of size 16 starts at ffff888120969690Data copied to user address 00000000200017c0CPU: 1 PID: 5050 Comm: syz-executor198 Not tainted 6.9.0-rc5-syzkaller-00031-g71b1543c83d6 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024(CVE-2024-42076)In the Linux kernel, the following vulnerability has been resolved:ocfs2: fix DIO failure due to insufficient transaction creditsThe code in ocfs2_dio_end_io_write() estimates number of necessarytransaction credits using ocfs2_calc_extend_credits().  This however doesnot take into account that the IO could be arbitrarily large and cancontain arbitrary number of extents.Extent tree manipulations do often extend the current transaction but notin all of the cases.  For example if we have only single block extents inthe tree, ocfs2_mark_extent_written() will end up callingocfs2_replace_extent_rec() all the time and we will never extend thecurrent transaction and eventually exhaust all the transaction credits ifthe IO contains many single block extents.  Once that happens aWARN_ON(jbd2_handle_buffer_credits(handle) &lt;= 0) is triggered injbd2_journal_dirty_metadata() and subsequently OCFS2 aborts in response tothis error.  This was actually triggered by one of our customers on aheavily fragmented OCFS2 filesystem.To fix the issue make sure the transaction always has enough credits forone extent insert before each call of ocfs2_mark_extent_written().Heming Zhao said:------PANIC: &#34;Kernel panic - not syncing: OCFS2: (device dm-1): panic forced after error&#34;PID: xxx  TASK: xxxx  CPU: 5  COMMAND: &#34;SubmitThread-CA&#34;  #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-42077)In the Linux kernel, the following vulnerability has been resolved:RDMA/restrack: Fix potential invalid address accessstruct rdma_restrack_entry&#39;s kern_name was set to KBUILD_MODNAMEin ib_create_cq(), while if the module exited but forgot del thisrdma_restrack_entry, it would cause a invalid address access inrdma_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 theULPs. But it is not needed anymore, so delete them.(CVE-2024-42080)In the Linux kernel, the following vulnerability has been resolved:xdp: Remove WARN() from __xdp_reg_mem_model()syzkaller reports a warning in __xdp_reg_mem_model().The warning occurs only if __mem_id_init_hash_table() returns an error. Itreturns the error in two cases:  1. memory allocation fails;  2. rhashtable_init() fails when some fields of rhashtable_params     struct are not initialized properly.The second case cannot happen since there is a static const rhashtable_paramsstruct with valid fields. So, warning is only triggered when there is aproblem with memory allocation.Thus, there is no sense in using WARN() to handle this error and it can besafely removed.WARNING: CPU: 0 PID: 5065 at net/core/xdp.c:299 __xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299CPU: 0 PID: 5065 Comm: syz-executor883 Not tainted 6.8.0-syzkaller-05271-gf99c5f563c17 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:__xdp_reg_mem_model+0x2d9/0x650 net/core/xdp.c:299Call Trace: xdp_reg_mem_model+0x22/0x40 net/core/xdp.c:344 xdp_test_run_setup net/bpf/test_run.c:188 [inline] bpf_test_run_xdp_live+0x365/0x1e90 net/bpf/test_run.c:377 bpf_prog_test_run_xdp+0x813/0x11b0 net/bpf/test_run.c:1267 bpf_prog_test_run+0x33a/0x3b0 kernel/bpf/syscall.c:4240 __sys_bpf+0x48d/0x810 kernel/bpf/syscall.c:5649 __do_sys_bpf kernel/bpf/syscall.c:5738 [inline] __se_sys_bpf kernel/bpf/syscall.c:5736 [inline] __x64_sys_bpf+0x7c/0x90 kernel/bpf/syscall.c:5736 do_syscall_64+0xfb/0x240 entry_SYSCALL_64_after_hwframe+0x6d/0x75Found by Linux Verification Center (linuxtesting.org) with syzkaller.(CVE-2024-42082)In the Linux kernel, the following vulnerability has been resolved:ftruncate: pass a signed offsetThe old ftruncate() syscall, using the 32-bit off_t misses a signextension when called in compat mode on 64-bit architectures.  As aresult, passing a negative length accidentally succeeds in truncatingto file size between 2GiB and 4GiB.Changing the type of the compat syscall to the signed compat_off_tchanges the behavior so it instead returns -EINVAL.The native entry point, the truncate() syscall and the correspondingloff_t based variants are all correct already and do not sufferfrom this mistake.(CVE-2024-42084)In the Linux kernel, the following vulnerability has been resolved:iio: chemical: bme680: Fix overflows in compensate() functionsThere are cases in the compensate functions of the driver thatthere could be overflows of variables due to bit shifting ops.These implications were initially discussed here [1] and theywere mentioned in log message of Commit 1b3bd8592780 (&#34;iio:chemical: Add support for Bosch BME680 sensor&#34;).[1]: https://lore.kernel.org/linux-iio/20180728114028.3c1bbe81@archlinux/(CVE-2024-42086)In the Linux kernel, the following vulnerability has been resolved:ASoC: fsl-asoc-card: set priv-&gt;pdev before using itpriv-&gt;pdev pointer was set after being used infsl_asoc_card_audmux_init().Move this assignment at the start of the probe function, sosub-functions can correctly use pdev through priv.fsl_asoc_card_audmux_init() dereferences priv-&gt;pdev to get access to thedev 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&#39;t crashprobably due to compiler optimisations.(CVE-2024-42089)In the Linux kernel, the following vulnerability has been resolved:pinctrl: fix deadlock in create_pinctrl() when handling -EPROBE_DEFERIn create_pinctrl(), pinctrl_maps_mutex is acquired before callingadd_setting(). If add_setting() returns -EPROBE_DEFER, create_pinctrl()calls pinctrl_free(). However, pinctrl_free() attempts to acquirepinctrl_maps_mutex, which is already held by create_pinctrl(), leading toa potential deadlock.This patch resolves the issue by releasing pinctrl_maps_mutex beforecalling pinctrl_free(), preventing the deadlock.This bug was discovered and resolved using Coverity Static AnalysisSecurity Testing (SAST) by Synopsys, Inc.(CVE-2024-42090)In the Linux kernel, the following vulnerability has been resolved:gpio: davinci: Validate the obtained number of IRQsValue of pdata-&gt;gpio_unbanked is taken from Device Tree. In case of brokenDT due to any error this value can be any. Without this value validationthere can be out of chips-&gt;irqs array boundaries access indavinci_gpio_probe().Validate the obtained nirq value so that it won&#39;t exceed the maximumnumber of IRQs per bank.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-42092)In the Linux kernel, the following vulnerability has been resolved:net/dpaa2: Avoid explicit cpumask var allocation on stackFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumaskvariable on stack is not recommended since it can cause potential stackoverflow.Instead, kernel code should always use *cpumask_var API(s) to allocatecpumask var in config-neutral way, leaving allocation strategy toCONFIG_CPUMASK_OFFSTACK.Use *cpumask_var API(s) to address it.(CVE-2024-42093)In the Linux kernel, the following vulnerability has been resolved:net/iucv: Avoid explicit cpumask var allocation on stackFor CONFIG_CPUMASK_OFFSTACK=y kernel, explicit allocation of cpumaskvariable on stack is not recommended since it can cause potential stackoverflow.Instead, kernel code should always use *cpumask_var API(s) to allocatecpumask var in config-neutral way, leaving allocation strategy toCONFIG_CPUMASK_OFFSTACK.Use *cpumask_var API(s) to address it.(CVE-2024-42094)In the Linux kernel, the following vulnerability has been resolved:ALSA: emux: improve patch ioctl data validationIn load_data(), make the validation of and skipping over the main infoblock match that in load_guspatch().In load_guspatch(), add checking that the specified patch length matchesthe actually supplied data, like load_data() already did.(CVE-2024-42097)In the Linux kernel, the following vulnerability has been resolved:drm/nouveau: fix null pointer dereference in nouveau_connector_get_modesIn nouveau_connector_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a possible NULL pointerdereference on failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42101)In the Linux kernel, the following vulnerability has been resolved:inet_diag: Initialize pad field in struct inet_diag_req_v2KMSAN reported uninit-value access in raw_lookup() [1]. Diag for rawsockets uses the pad field in struct inet_diag_req_v2 for theunderlying protocol. This field corresponds to the sdiag_raw_protocolfield in struct inet_diag_req_raw.inet_diag_get_exact_compat() converts inet_diag_req toinet_diag_req_v2, but leaves the pad field uninitialized. So the issueoccurs when raw_lookup() accesses the sdiag_raw_protocol field.Fix this by initializing the pad field ininet_diag_get_exact_compat(). Also, do the same fix ininet_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/0x7fUninit 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/0x7fLocal 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:282CPU: 1 PID: 8888 Comm: syz-executor.6 Not tainted 6.10.0-rc4-00217-g35bb670d65fc #32Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014(CVE-2024-42106)In the Linux kernel, the following vulnerability has been resolved:jffs2: Fix potential illegal address access in jffs2_free_inodeDuring the stress testing of the jffs2 file system,the followingabnormal 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/0x54The parameter passed to kfree was 5a5a5a5a, which corresponds to the target field ofthe jffs_inode_info structure. It was found that all variables in the jffs_inode_infostructure were 5a5a5a5a, except for the first member sem. It is suspected that thesevariables 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 thefunction jffs2_i_init_once, while other members are initialized inthe 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 inodeis not initialized.In concurrent high pressure scenarios, iget_lockedmay 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-42115)In the Linux kernel, the following vulnerability has been resolved:scsi: qedf: Make qedf_execute_tmf() non-preemptibleStop calling smp_processor_id() from preemptible code inqedf_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-42124)In the Linux kernel, the following vulnerability has been resolved:leds: mlxreg: Use devm_mutex_init() for mutex initializationIn this driver LEDs are registered using devm_led_classdev_register()so they are automatically unregistered after module&#39;s remove() is done.led_classdev_unregister() calls module&#39;s led_set_brightness() to turn offthe LEDs and that callback uses mutex which was destroyed alreadyin module&#39;s remove() so use devm API instead.(CVE-2024-42129)In the Linux kernel, the following vulnerability has been resolved:IB/core: Implement a limit on UMAD receive ListThe existing behavior of ib_umad, which maintains received MADpackets in an unbounded list, poses a risk of uncontrolled growth.As user-space applications extract packets from this list, the rateof extraction may not match the rate of incoming packets, leadingto potential list overflow.To address this, we introduce a limit to the size of the list. Afterconsidering typical scenarios, such as OpenSM processing, which canhandle approximately 100k packets per second, and the 1-second retrytimeout for most packets, we set the list size limit to 200k. Packetsreceived beyond this limit are dropped, assuming they are likely timedout by the time they are handled by user-space.Notably, packets queued on the receive list due to reasons liketimed-out sends are preserved even when the list is full.(CVE-2024-42145)In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe copies of protected- and secure-keysAlthough the clear-key of neither protected- nor secure-keys isaccessible, this key material should only be visible to the callingprocess. So wipe all copies of protected- or secure-keys from stack,even in case of an error.(CVE-2024-42155)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&#39;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-42160)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&#39;.]GCC warns that `val&#39; may be used uninitialized in theBPF_CRE_READ_BITFIELD macro, defined in bpf_core_read.h as:&#x9;[...]&#x9;unsigned long long val;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;      \&#x9;[...]&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;      \&#x9;switch (__CORE_RELO(s, field, BYTE_SIZE)) {&#x9;&#x9;&#x9;      \&#x9;case 1: val = *(const unsigned char *)p; break;&#x9;&#x9;&#x9;      \&#x9;case 2: val = *(const unsigned short *)p; break;&#x9;&#x9;      \&#x9;case 4: val = *(const unsigned int *)p; break;&#x9;&#x9;&#x9;      \&#x9;case 8: val = *(const unsigned long long *)p; break;&#x9;&#x9;      \        }       &#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;      \&#x9;[...]&#x9;val;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;      \&#x9;}&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;&#x9;      \This patch adds a default entry in the switch statement that sets`val&#39; 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-42161)In the Linux kernel, the following vulnerability has been resolved:gve: Account for stopped queues when reading NIC statsWe now account for the fact that the NIC might send us stats for asubset of queues. Without this change, gve_get_ethtool_stats might makean invalid access on the priv-&gt;stats_report-&gt;stats array.(CVE-2024-42162)In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Correct check for empty listSince commit a3c53be55c95 (&#34;net: dsa: mv88e6xxx: Support multiple MDIObusses&#34;) 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-42224)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-42228)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.88.0.169.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.88.0.169.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1966</id>
          <title>An update for qpdf is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-34503" id="CVE-2022-34503" title="CVE-2022-34503" type="cve"></reference>
          </references>
          <description>QPDF v8.4.2 was discovered to contain a heap buffer overflow via the function QPDF::processXRefStream. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted PDF file.(CVE-2022-34503)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qpdf" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-8.4.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf-debuginfo" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-debuginfo-8.4.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf-debugsource" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-debugsource-8.4.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qpdf-devel" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-devel-8.4.2-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qpdf-help" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-help-8.4.2-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-8.4.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-debuginfo" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-debuginfo-8.4.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-debugsource" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-debugsource-8.4.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qpdf-devel" release="5.oe2203sp1" version="8.4.2">
                         <filename>qpdf-devel-8.4.2-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1973</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1737" id="CVE-2024-1737" title="CVE-2024-1737" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-1975" id="CVE-2024-1975" title="CVE-2024-1975" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4076" id="CVE-2024-4076" title="CVE-2024-4076" type="cve"></reference>
          </references>
          <description>Berkeley Internet Name Domain (BIND) is an implementation of the Domain Name System (DNS) protocols and provides an openly redistributable reference implementation of the major components of the Domain Name System. This package includes the components to operate a DNS server.Security Fix(es):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.(CVE-2024-1737)If a server hosts a zone containing a &#34;KEY&#34; Resource Record, or a resolver DNSSEC-validates a &#34;KEY&#34; Resource Record from a DNSSEC-signed domain in cache, a client can exhaust resolver CPU resources by sending a stream of SIG(0) signed requests.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-1975)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-4076)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="32" arch="aarch64" name="bind" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-license-9.16.23-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="23.oe2203sp1" version="9.16.23">
                         <filename>python3-bind-9.16.23-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1975</id>
          <title>An update for orc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-09"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40897" id="CVE-2024-40897" title="CVE-2024-40897" type="cve"></reference>
          </references>
          <description>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&#39;s build environment. This may lead to compromise of developer machines or CI build environments.(CVE-2024-40897)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="orc" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-0.4.32-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-compiler" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-compiler-0.4.32-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-debuginfo" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-debuginfo-0.4.32-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-debugsource" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-debugsource-0.4.32-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-devel" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-devel-0.4.32-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="orc-help" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-help-0.4.32-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-0.4.32-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-compiler" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-compiler-0.4.32-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-debuginfo" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-debuginfo-0.4.32-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-debugsource" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-debugsource-0.4.32-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-devel" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-devel-0.4.32-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="orc-help" release="3.oe2203sp1" version="0.4.32">
                         <filename>orc-help-0.4.32-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1977</id>
          <title>An update for postgresql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7348" id="CVE-2024-7348" title="CVE-2024-7348" type="cve"></reference>
          </references>
          <description>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-7348)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="postgresql" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-contrib" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-contrib-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debuginfo" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-debuginfo-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-debugsource" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-debugsource-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-docs" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-docs-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-llvmjit" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-llvmjit-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plperl" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-plperl-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-plpython3" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-plpython3-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-pltcl" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-pltcl-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-devel" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-private-devel-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-private-libs" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-private-libs-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-server-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-server-devel" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-server-devel-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-static" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-static-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="postgresql-test" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-test-13.16-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="postgresql-test-rpm-macros" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-test-rpm-macros-13.16-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-contrib" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-contrib-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debuginfo" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-debuginfo-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-debugsource" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-debugsource-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-docs" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-docs-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-llvmjit" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-llvmjit-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plperl" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-plperl-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-plpython3" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-plpython3-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-pltcl" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-pltcl-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-devel" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-private-devel-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-private-libs" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-private-libs-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-server-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-server-devel" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-server-devel-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-static" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-static-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="postgresql-test" release="1.oe2203sp1" version="13.16">
                         <filename>postgresql-test-13.16-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1980</id>
          <title>An update for golang is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24791" id="CVE-2024-24791" title="CVE-2024-24791" type="cve"></reference>
          </references>
          <description>The net/http HTTP/1.1 client mishandled the case where a server responds to a request with an &#34;Expect: 100-continue&#34; header with a non-informational (200 or higher) status. This mishandling could leave a client connection in an invalid state, where the next request sent on the connection will fail. An attacker sending a request to a net/http/httputil.ReverseProxy proxy can exploit this mishandling to cause a denial of service by sending &#34;Expect: 100-continue&#34; requests which elicit a non-informational response from the backend. Each such request leaves the proxy with an invalid connection, and causes one subsequent request using that connection to fail.(CVE-2024-24791)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="golang" release="35.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-35.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-devel" release="35.oe2203sp1" version="1.17.3">
                         <filename>golang-devel-1.17.3-35.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="golang-help" release="35.oe2203sp1" version="1.17.3">
                         <filename>golang-help-1.17.3-35.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="golang" release="35.oe2203sp1" version="1.17.3">
                         <filename>golang-1.17.3-35.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1982</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41957" id="CVE-2024-41957" title="CVE-2024-41957" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41965" id="CVE-2024-41965" title="CVE-2024-41965" type="cve"></reference>
          </references>
          <description>Vim is an open source command line text editor. Vim &lt; v9.1.0647 has double free in src/alloc.c:616. When closing a window, the corresponding tagstack data will be cleared and freed. However a bit later, the quickfix list belonging to that window will also be cleared and if that quickfix list points to the same tagstack data, Vim will try to free it again, resulting in a double-free/use-after-free access exception. Impact is low since the user must intentionally execute vim with several non-default flags,but it may cause a crash of Vim. The issue has been fixed as of Vim patch v9.1.0647(CVE-2024-41957)Vim is an open source command line text editor. double-free in dialog_changed() in Vim &lt; v9.1.0648. When abandoning a buffer, Vim may ask the user what to do with the modified buffer. If the user wants the changed buffer to be saved, Vim may create a new Untitled file, if the buffer did not have a name yet. However, when setting the buffer name to Unnamed, Vim will falsely free a pointer twice, leading to a double-free and possibly later to a heap-use-after-free, which can lead to a crash. The issue has been fixed as of Vim patch v9.1.0648.(CVE-2024-41965)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="vim-X11" release="24.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-common" release="24.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-debuginfo" release="24.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-debugsource" release="24.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-enhanced" release="24.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-minimal" release="24.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-24.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="vim-filesystem" release="24.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-24.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-X11" release="24.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-common" release="24.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-debuginfo" release="24.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-debugsource" release="24.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-enhanced" release="24.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-minimal" release="24.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-24.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1986</id>
          <title>An update for python-twisted is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41671" id="CVE-2024-41671" title="CVE-2024-41671" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41810" id="CVE-2024-41810" title="CVE-2024-41810" type="cve"></reference>
          </references>
          <description>Twisted is an event-based framework for internet applications, supporting Python 3.6+. The HTTP 1.0 and 1.1 server provided by twisted.web could process pipelined HTTP requests out-of-order, possibly resulting in information disclosure. This vulnerability is fixed in 24.7.0rc1.(CVE-2024-41671)Twisted is an event-based framework for internet applications, supporting Python 3.6+. The `twisted.web.util.redirectTo` function contains an HTML injection vulnerability. If application code allows an attacker to control the redirect URL this vulnerability may result in Reflected Cross-Site Scripting (XSS) in the redirect response HTML body. This vulnerability is fixed in 24.7.0rc1.(CVE-2024-41810)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-twisted" release="4.oe2203sp1" version="22.4.0">
                         <filename>python3-twisted-22.4.0-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python-twisted-help" release="4.oe2203sp1" version="22.4.0">
                         <filename>python-twisted-help-22.4.0-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-twisted" release="4.oe2203sp1" version="22.4.0">
                         <filename>python3-twisted-22.4.0-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1989</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7409" id="CVE-2024-7409" title="CVE-2024-7409" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-7409)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-97.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-97.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="97.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-97.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1992</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47582" id="CVE-2021-47582" title="CVE-2021-47582" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48827" id="CVE-2022-48827" title="CVE-2022-48827" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52888" id="CVE-2023-52888" title="CVE-2023-52888" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39509" id="CVE-2024-39509" title="CVE-2024-39509" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40942" id="CVE-2024-40942" title="CVE-2024-40942" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40990" id="CVE-2024-40990" title="CVE-2024-40990" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41012" id="CVE-2024-41012" title="CVE-2024-41012" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41034" id="CVE-2024-41034" title="CVE-2024-41034" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41035" id="CVE-2024-41035" title="CVE-2024-41035" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41042" id="CVE-2024-41042" title="CVE-2024-41042" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41046" id="CVE-2024-41046" title="CVE-2024-41046" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41065" id="CVE-2024-41065" title="CVE-2024-41065" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41078" id="CVE-2024-41078" title="CVE-2024-41078" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41092" id="CVE-2024-41092" title="CVE-2024-41092" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42087" id="CVE-2024-42087" title="CVE-2024-42087" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42095" id="CVE-2024-42095" title="CVE-2024-42095" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42096" id="CVE-2024-42096" title="CVE-2024-42096" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42098" id="CVE-2024-42098" title="CVE-2024-42098" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42102" id="CVE-2024-42102" title="CVE-2024-42102" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42105" id="CVE-2024-42105" title="CVE-2024-42105" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42114" id="CVE-2024-42114" title="CVE-2024-42114" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42128" id="CVE-2024-42128" title="CVE-2024-42128" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42143" id="CVE-2024-42143" title="CVE-2024-42143" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42148" id="CVE-2024-42148" title="CVE-2024-42148" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42154" id="CVE-2024-42154" title="CVE-2024-42154" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42156" id="CVE-2024-42156" title="CVE-2024-42156" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42157" id="CVE-2024-42157" title="CVE-2024-42157" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42223" id="CVE-2024-42223" title="CVE-2024-42223" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42225" id="CVE-2024-42225" title="CVE-2024-42225" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42229" id="CVE-2024-42229" title="CVE-2024-42229" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42244" id="CVE-2024-42244" title="CVE-2024-42244" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42246" id="CVE-2024-42246" title="CVE-2024-42246" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42247" id="CVE-2024-42247" title="CVE-2024-42247" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:USB: core: Make do_proc_control() and do_proc_bulk() killableThe USBDEVFS_CONTROL and USBDEVFS_BULK ioctls invokeusb_start_wait_urb(), which contains an uninterruptible wait with auser-specified timeout value.  If timeout value is very large and thedevice being accessed does not respond in a reasonable amount of time,the kernel will complain about &#34;Task X blocked for more than Nseconds&#34;, 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&#34;echo 0 &gt; /proc/sys/kernel/hung_task_timeout_secs&#34; disables this message.task:syz-executor.0  state:D stack:23192 pid: 8700 ppid:  8455 flags:0x00004004Call 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&#39;s calls tousb_control_msg() and usb_bulk_msg() with special-purpose code thatdoes essentially the same thing (as recommended in the comment forusb_start_wait_urb()), except that it always uses a killable wait andit uses GFP_KERNEL rather than GFP_NOIO.(CVE-2021-47582)In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix the behavior of READ near OFFSET_MAXDan Aloni reports:&gt; Due to commit 8cfb9015280d (&#34;NFS: Always provide aligned buffers to&gt; the RPC read layers&#34;) 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 allNFS specifications permit servers to return that status code for aREAD.Instead of NFS?ERR_INVAL, have out-of-range READ requests succeedand return a short result. Set the EOF flag in the result to preventthe client from retrying the READ request. This behavior appears tobe consistent with Solaris NFS servers.Note that NFSv3 and NFSv4 use u64 offset values on the wire. Thesemust be converted to loff_t internally before use -- an implicittype cast is not adequate for this purpose. Otherwise VFS checksagainst sb-&gt;s_maxbytes do not work properly.(CVE-2022-48827)In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Only free buffer VA that is not NULLIn the MediaTek vcodec driver, while mtk_vcodec_mem_free() is mostlycalled only when the buffer to free exists, there are some instancesthat didn&#39;t do the check and triggered warnings in practice.We believe those checks were forgotten unintentionally. Add the checksback to fix the warnings.(CVE-2023-52888)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 tryingto write a value into a field of smaller size in an output report.Since implement() already has a warn message printed out with thehelp of hid_warn() and value in question gets trimmed with:&#x9;...&#x9;value &amp;= m;&#x9;...WARN_ON may be considered superfluous. Remove it to suppress futuresyzkaller 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:1863Modules linked in:CPU: 0 PID: 5084 Comm: syz-executor424 Not tainted 6.9.0-rc7-syzkaller-00183-gcf87f46fd34d #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 04/02/2024RIP: 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-2024-39509)In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: mesh: Fix leak of mesh_preq_queue objectsThe hwmp code use objects of type mesh_preq_queue, added to a list inieee80211_if_mesh, to keep track of mpath we need to resolve. If the mpathgets deleted, ex mesh interface is removed, the entries in that list willnever get cleaned. Fix this by flushing all corresponding items of thepreq_queue in mesh_path_flush_pending().This should take care of KASAN reports like this:unreferenced object 0xffff00000668d800 (size 128):  comm &#34;kworker/u8:4&#34;, 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/0x20unreferenced object 0xffff000009051f00 (size 128):  comm &#34;kworker/u8:4&#34;, 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&#39;.......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-40942)In the Linux kernel, the following vulnerability has been resolved:RDMA/mlx5: Add check for srq max_sge attributemax_sge attribute is passed by the user, and is inserted and usedunchecked, so verify that the value doesn&#39;t exceed maximum allowed valuebefore using it.(CVE-2024-40990)In the Linux kernel, the following vulnerability has been resolved:filelock: Remove locks reliably when fcntl/close race is detectedWhen fcntl_setlk() races with close(), it removes the created lock withdo_lock_file_wait().However, LSMs can allow the first do_lock_file_wait() that created the lockwhile denying the second do_lock_file_wait() that tries to remove the lock.Separately, posix_lock_file() could also fail toremove a lock due to GFP_KERNEL allocation failure (when splitting a rangein the middle).After the bug has been triggered, use-after-free reads will occur inlock_get_status() when userspace reads /proc/locks. This can likely be usedto read arbitrary kernel memory, but can&#39;t corrupt kernel memory.Fix it by calling locks_remove_posix() instead, which is designed toreliably get rid of POSIX locks associated with the given file andfiles_struct and is also used by filp_flush().(CVE-2024-41012)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix kernel bug on rename operation of broken directorySyzbot reported that in rename directory operation on broken directory onnilfs2, __block_write_begin_int() called to prepare block write may failBUG_ON check for access exceeding the folio/page size.This is because nilfs_dotdot(), which gets parent directory referenceentry (&#34;..&#34;) of the directory to be moved or renamed, does not checkconsistency enough, and may return location exceeding folio/page size forbroken directories.Fix this issue by checking required directory entries (&#34;.&#34; and &#34;..&#34;) inthe first chunk of the directory in nilfs_dotdot().(CVE-2024-41034)In the Linux kernel, the following vulnerability has been resolved:USB: core: Fix duplicate endpoint bug by clearing reserved bits in the descriptorSyzbot has identified a bug in usbcore (see the Closes: tag below)caused by our assumption that the reserved bits in an endpointdescriptor&#39;s bEndpointAddress field will always be 0.  As a result ofthe bug, the endpoint_is_duplicate() routine in config.c (and possiblyother routines as well) may believe that two descriptors are fordistinct endpoints, even though they have the same direction andendpoint number.  This can lead to confusion, including the bugidentified by syzbot (two descriptors with matching endpoint numbersand directions, where one was interrupt and the other was bulk).To fix the bug, we will clear the reserved bits in bEndpointAddresswhen we parse the descriptor.  (Note that both the USB-2.0 and USB-3.1specs say these bits are &#34;Reserved, reset to zero&#34;.)  This requires usto make a copy of the descriptor earlier in usb_parse_endpoint() anduse the copy instead of the original when checking for duplicates.(CVE-2024-41035)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: prefer nft_chain_validatenft_chain_validate already performs loop detection because a cycle willresult 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 thereappears 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 inunbounded recursion:BUG: TASK stack guard page was hit at ....Oops: stack guard page: 0000 [#1] PREEMPT SMP KASANCPU: 4 PID: 1539 Comm: nft Not tainted 6.10.0-rc5+ #1[..]with a suitable ruleset during validation of register stores.I can&#39;t see any actual reason to attempt to check for this fromnft_validate_register_store(), at this point the transaction is still inprogress, so we don&#39;t have a full picture of the rule graph.For nf-next it might make sense to either remove it or make this dependon table-&gt;validate_state in case we could catch an error earlier(for improved error reporting to userspace).(CVE-2024-41042)In the Linux kernel, the following vulnerability has been resolved:net: ethernet: lantiq_etop: fix double free in detachThe number of the currently released descriptor is never incrementedwhich results in the same skb being released multiple times.(CVE-2024-41046)In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Whitelist dtl slub object for copying to userspaceReading the dispatch trace log from /sys/kernel/debug/powerpc/dtl/cpu-*results in a BUG() when the config CONFIG_HARDENED_USERCOPY is enabled asshown 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 0x7fff81f3ab34Commit 6d07d1cd300f (&#34;usercopy: Restrict non-usercopy caches to size 0&#34;)requires that only whitelisted areas in slab/slub objects can be copied touserspace when usercopy hardening is enabled using CONFIG_HARDENED_USERCOPY.Dtl contains hypervisor dispatch events which are expected to be read byprivileged users. Hence mark this safe for user access.Specify useroffset=0 and usersize=DISPATCH_LOG_BYTES to whitelist theentire object.(CVE-2024-41065)In the Linux kernel, the following vulnerability has been resolved:btrfs: qgroup: fix quota root leak after quota disable failureIf during the quota disable we fail when cleaning the quota tree or whendeleting the root from the root tree, we jump to the &#39;out&#39; label withoutever dropping the reference on the quota root, resulting in a leak of theroot since fs_info-&gt;quota_root is no longer pointing to the root (we haveset it to NULL just before those steps).Fix this by always doing a btrfs_put_root() call under the &#39;out&#39; label.This is a problem that exists since qgroups were first added in 2012 bycommit bed92eae26cc (&#34;Btrfs: qgroup implementation and prototypes&#34;), butback 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 notyet reference counted.(CVE-2024-41078)In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Fix potential UAF by revoke of fence registersCI has been sporadically reporting the following issue triggered byigt@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 IGTtests, observed on other platforms.Before commit 63baf4f3d587 (&#34;drm/i915/gt: Only wait for GPU activitybefore unbinding a GGTT fence&#34;), i915_vma_revoke_fence() was waiting foridleness of vma-&gt;active via fence_update().   That commit introducedvma-&gt;fence-&gt;active in order for the fence_update() to be able to waitselectively on that one instead of vma-&gt;active since only idleness offence registers was needed.  But then, another commit 0d86ee35097a(&#34;drm/i915/gt: Make fence revocation unequivocal&#34;) replaced the call tofence_update() in i915_vma_revoke_fence() with only fence_write(), andalso 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 ofvma-&gt;fence-&gt;active without first waiting on it.The issue can be potentially caused by a race among revocation of fenceregisters on one side and sequential execution of signal callbacks invokedon completion of a request that was using them on the other, stillprocessed in parallel to revocation of those fence registers.  Fix it bywaiting for idleness of vma-&gt;fence-&gt;active in i915_vma_revoke_fence().(cherry picked from commit 24bb052d3dd499c5956abad5f7d8e4fd07da7fb1)(CVE-2024-41092)In the Linux kernel, the following vulnerability has been resolved:drm/panel: ilitek-ili9881c: Fix warning with GPIO controllers that sleepThe ilitek-ili9881c controls the reset GPIO using the non-sleepinggpiod_set_value() function. This complains loudly when the GPIOcontroller needs to sleep. As the caller can sleep, usegpiod_set_value_cansleep() to fix the issue.(CVE-2024-42087)In the Linux kernel, the following vulnerability has been resolved:serial: 8250_omap: Implementation of Errata i2310As per Errata i2310[0], Erroneous timeout can be triggered,if this Erroneous interrupt is not cleared then it may leadsto storm of interrupts, therefore apply Errata i2310 solution.[0] https://www.ti.com/lit/pdf/sprz536 page 23(CVE-2024-42095)In the Linux kernel, the following vulnerability has been resolved:x86: stop playing stack games in profile_pc()The &#39;profile_pc()&#39; function is used for timer-based profiling, whichisn&#39;t really all that relevant any more to begin with, but it also endsup making assumptions based on the stack layout that aren&#39;t necessarilyvalid.Basically, the code tries to account the time spent in spinlocks to thecaller rather than the spinlock, and while I support that as a concept,it&#39;s not worth the code complexity or the KASAN warnings when no seriousprofiling is done using timers anyway these days.And the code really does depend on stack layout that is only true in thesimplest of cases.  We&#39;ve lost the comment at some point (I think whenthe 32-bit and 64-bit code was unified), but it used to say:&#x9;Assume the lock function has either no stack frame or a copy&#x9;of eflags from PUSHF.which explains why it just blindly loads a word or two straight off thestack pointer and then takes a minimal look at the values to just checkif they might be eflags or the return pc:&#x9;Eflags always has bits 22 and up cleared unlike kernel addressesbut that basic stack layout assumption assumes that there isn&#39;t any lockdebugging etc going on that would complicate the code and cause a stackframe.It causes KASAN unhappiness reported for years by syzkaller [1] andothers [2].With no real practical reason for this any more, just remove the code.Just for historical interest, here&#39;s some background commits relating tothis code from 2006:  0cb91a229364 (&#34;i386: Account spinlocks to the caller during profiling for !FP kernels&#34;)  31679f38d886 (&#34;Simplify profile_pc on x86-64&#34;)and a code unification from 2009:  ef4512882dbe (&#34;x86: time_32/64.c unify profile_pc&#34;)but the basics of this thing actually goes back to before the git tree.(CVE-2024-42096)In the Linux kernel, the following vulnerability has been resolved:crypto: ecdh - explicitly zeroize private_keyprivate_key is overwritten with the key parameter passed in by thecaller (if present), or alternatively a newly generated private key.However, it is possible that the caller provides a key (or the newlygenerated key) which is shorter than the previous key. In thatscenario, some key material from the previous key would not beoverwritten. The easiest solution is to explicitly zeroize the entireprivate_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 wouldremain. Now, the private_key is always zeroized. This behavior isconsistent with the case where params.key is set and ecc_is_key_validfails.(CVE-2024-42098)In the Linux kernel, the following vulnerability has been resolved:Revert &#34;mm/writeback: fix possible divide-by-zero in wb_dirty_limits(), again&#34;Patch series &#34;mm: Avoid possible overflows in dirty throttling&#34;.Dirty throttling logic assumes dirty limits in page units fit into32-bits.  This patch series makes sure this is true (see patch 2/2 formore details).This patch (of 2):This reverts commit 9319b647902cbd5cc884ac08a8a6d54ce111fc78.The commit is broken in several ways.  Firstly, the removed (u64) castfrom the multiplication will introduce a multiplication overflow on 32-bitarchs if wb_thresh * bg_thresh &gt;= 1&lt;&lt;32 (which is actually common - thedefault settings with 4GB of RAM will trigger this).  Secondly, thediv64_u64() is unnecessarily expensive on 32-bit archs.  We havediv64_ul() in case we want to be safe &amp; cheap.  Thirdly, if dirtythresholds are larger than 1&lt;&lt;32 pages, then dirty balancing is going toblow up in many other spectacular ways anyway so trying to fix onepossible overflow is just moot.(CVE-2024-42102)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix inode number range checksPatch series &#34;nilfs2: fix potential issues related to reserved inodes&#34;.This series fixes one use-after-free issue reported by syzbot, caused bynilfs2&#39;s internal inode being exposed in the namespace on a corruptedfilesystem, and a couple of flaws that cause problems if the startingnumber of non-reserved inodes written in the on-disk super block isintentionally (or corruptly) changed from its default value.  This patch (of 3):In the current implementation of nilfs2, &#34;nilfs-&gt;ns_first_ino&#34;, whichgives 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 ofreserved inodes such as the root directory or metadata files is set in thesuper block parameter, the inode number test macros (NILFS_MDT_INODE andNILFS_VALID_INODE) will not function properly.In addition, these test macros use left bit-shift calculations using withthe inode number as the shift count via the BIT macro, but the result of ashift calculation that exceeds the bit width of an integer is undefined inthe C specification, so if &#34;ns_first_ino&#34; is set to a large value otherthan the default value NILFS_USER_INO (=11), the macros may potentiallymalfunction depending on the environment.Fix these issues by checking the lower bound of &#34;nilfs-&gt;ns_first_ino&#34; andby preventing bit shifts equal to or greater than the NILFS_USER_INOconstant in the inode number test macros.Also, change the type of &#34;ns_first_ino&#34; from signed integer to unsignedinteger to avoid the need for type casting in comparisons such as thelower bound check introduced this time.(CVE-2024-42105)In the Linux kernel, the following vulnerability has been resolved:wifi: cfg80211: restrict NL80211_ATTR_TXQ_QUANTUM valuessyzbot is able to trigger softlockups, setting NL80211_ATTR_TXQ_QUANTUMto 2^31.We had a similar issue in sch_fq, fixed with commitd9e15a273306 (&#34;pkt_sched: fq: do not accept silly TCA_FQ_QUANTUM&#34;)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:19CPU: 1 PID: 24 Comm: kworker/1:0 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Workqueue: mld mld_ifc_workpstate: 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:3854sp : ffff800093d36700x29: ffff800093d36a60 x28: ffff800093d36960 x27: dfff800000000000x26: ffff0000d800ad50 x25: ffff0000d800abe0 x24: ffff0000d800abf0x23: ffff0000e0032468 x22: ffff0000e00324d4 x21: ffff0000d800abf0x20: ffff0000d800abf8 x19: ffff0000d800abf0 x18: ffff800093d363c0x17: 000000000000d476 x16: ffff8000805519dc x15: ffff7000127a6cc8x14: 1ffff000127a6cc8 x13: 0000000000000004 x12: ffffffffffffffffx11: ffff7000127a6cc8 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 0000000000000000 x7 : 0000000000000000 x6 : 0000000000000000x5 : ffff80009287aa08 x4 : 0000000000000008 x3 : ffff80008034c7fcx2 : ffff0000e0032468 x1 : 00000000da0e46b8 x0 : ffff0000e0032470Call 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-42114)In the Linux kernel, the following vulnerability has been resolved:leds: an30259a: Use devm_mutex_init() for mutex initializationIn this driver LEDs are registered using devm_led_classdev_register()so they are automatically unregistered after module&#39;s remove() is done.led_classdev_unregister() calls module&#39;s led_set_brightness() to turn offthe LEDs and that callback uses mutex which was destroyed alreadyin module&#39;s remove() so use devm API instead.(CVE-2024-42128)In the Linux kernel, the following vulnerability has been resolved:orangefs: fix out-of-bounds fsid accessArnd Bergmann sent a patch to fsdevel, he says:&#34;orangefs_statfs() copies two consecutive fields of the superblock intothe statfs structure, which triggers a warning from the string fortificationhelpers&#34;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 patchis based on Jan Kara&#39;s suggestion.(CVE-2024-42143)In the Linux kernel, the following vulnerability has been resolved:bnx2x: Fix multiple UBSAN array-index-out-of-boundsFix UBSAN warnings that occur when using a system with 32 physicalcpu cores or more, or when the user defines a number of Ethernetqueues greater than or equal to FP_SB_MAX_E1x using the num_queuesmodule parameter.Currently there is a read/write out of bounds that occurs on the array&#34;struct stats_query_entry query&#34; present inside the &#34;bnx2x_fw_stats_req&#34;struct in &#34;drivers/net/ethernet/broadcom/bnx2x/bnx2x.h&#34;.Looking at the definition of the &#34;struct stats_query_entry query&#34; 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 andhas a value of 16, while BNX2X_FIRST_QUEUE_QUERY_IDX has a value of 3meaning the array has a total size of 19.Since accesses to &#34;struct stats_query_entry query&#34; are offset-ted byBNX2X_FIRST_QUEUE_QUERY_IDX, that means that the total number of Ethernetqueues should not exceed FP_SB_MAX_E1x (16). However one of these queuesis reserved for FCOE and thus the number of Ethernet queues should be setto [FP_SB_MAX_E1x -1] (15) if FCOE is enabled or [FP_SB_MAX_E1x] (16) ifit is not.This is also described in a comment in the source code indrivers/net/ethernet/broadcom/bnx2x/bnx2x.h just above the Macro definitionof FP_SB_MAX_E1x. Below is the part of this explanation that it importantfor 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 canhandle 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 originallyusing the E1x parameters: commit f2e0899f0f27 (&#34;bnx2x: Add 57712 support&#34;).Back then FP_SB_MAX_E2 was set to 16 the same as E1x. However the driverwas later updated to take full advantage of the E2 instead of having it belimited to the capabilities of the E1x. But as far as we can tell, thearray &#34;stats_query_entry query&#34; was still limited to using the FP-SBavailable to the E1x cards as part of an oversignt when the driver wasupdated to take full advantage of the E2, and now with the driver beingaware of the greater queue size supported by E2 NICs, it causes the UBSANwarnings seen in the stack traces below.This patch increases the size of the &#34;stats_query_entry query&#34; array byreplacing FP_SB_MAX_E1x with FP_SB_MAX_E2 to be large enough to handleboth types of NICs.Stack traces:UBSAN: array-index-out-of-bounds in       drivers/net/ethernet/broadcom/bnx2x/bnx2x_stats.c:1529:11index 20 is out of range for type &#39;stats_query_entry [19]&#39;CPU: 12 PID: 858 Comm: systemd-network Not tainted 6.9.0-060900rc7-generic&#x9;     #202405052133Hardware name: HP ProLiant DL360 Gen9/ProLiant DL360 ---truncated---(CVE-2024-42148)In the Linux kernel, the following vulnerability has been resolved:tcp_metrics: validate source addr lengthI don&#39;t see anything checking that TCP_METRICS_ATTR_SADDR_IPV4is at least 4 bytes long, and the policy doesn&#39;t have an entryfor this attribute at all (neither does it for IPv6 but v6 ismanually validated).(CVE-2024-42154)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-42156)In the Linux kernel, the following vulnerability has been resolved:s390/pkey: Wipe sensitive data on failureWipe sensitive data from stack also if the copy_to_user() fails.(CVE-2024-42157)In the Linux kernel, the following vulnerability has been resolved:media: dvb-frontends: tda10048: Fix integer overflowstate-&gt;xtal_hz can be up to 16M, so it can overflow a 32 bit integerwhen multiplied by pll_mfactor.Create a new 64 bit variable to hold the calculations.(CVE-2024-42223)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-42225)In the Linux kernel, the following vulnerability has been resolved:crypto: aead,cipher - zeroize key buffer after useI.G 9.7.B for FIPS 140-3 specifies that variables temporarily holdingcryptographic information should be zeroized once they are no longerneeded. Accomplish this by using kfree_sensitive for buffers thatpreviously held the private key.(CVE-2024-42229)In the Linux kernel, the following vulnerability has been resolved:USB: serial: mos7840: fix crash on resumeSince commit c49cfa917025 (&#34;USB: serial: use generic method if noalternative is provided in usb serial layer&#34;), USB serial core calls thegeneric resume implementation when the driver has not provided one.This can trigger a crash on resume with mos7840 since support formultiple read URBs was added back in 2011. Specifically, both port readURBs are now submitted on resume for open ports, but the context pointerof the second URB is left set to the core rather than mos7840 portstructure.Fix this by implementing dedicated suspend and resume functions formos7840.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-42244)In the Linux kernel, the following vulnerability has been resolved:net, sunrpc: Remap EPERM in case of connection failure in xs_tcp_setup_socketWhen using a BPF program on kernel_connect(), the call can return -EPERM. Thiscauses xs_tcp_setup_socket() to loop forever, filling up the syslog and causingthe 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 errorcan be out of reach (see handling in 4fbac77d2d09) in particular on kernelswhich do not have f10d05966196 (&#34;bpf: Make BPF_PROG_RUN_ARRAY return -errinstead of allow boolean&#34;), thus given that it is better to simply remap forconsistent behavior. UDP does handle EPERM in xs_udp_send_request().(CVE-2024-42246)In the Linux kernel, the following vulnerability has been resolved:wireguard: allowedips: avoid unaligned 64-bit memory accessesOn the parisc platform, the kernel issues kernel warnings becauseswap_endian() tries to load a 128-bit IPv6 address from an unalignedmemory 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 theget_unaligned_be64() helper macro.[Jason: replace src[8] in original patch with src+8](CVE-2024-42247)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.89.0.170.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.89.0.170.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.89.0.170.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-1999</id>
          <title>An update for texlive-base is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-08-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46048" id="CVE-2023-46048" title="CVE-2023-46048" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-46048)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="texlive-afm2pl" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-afm2pl-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-aleph" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-aleph-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-autosp" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-autosp-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-axodraw2" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-axodraw2-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-base" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-base-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-base-debuginfo" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-base-debuginfo-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-base-debugsource" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-base-debugsource-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bibtex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtex8" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bibtex8-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-bibtexu" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bibtexu-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-chktex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-chktex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-cjkutils" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-cjkutils-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ctie" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ctie-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-cweb" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-cweb-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-detex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-detex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dtl" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dtl-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvi2tty" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvi2tty-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvicopy" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvicopy-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvidvi" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvidvi-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dviljk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dviljk-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipdfmx" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvipdfmx-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipng" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvipng-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvipos" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvipos-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvips" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvips-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-dvisvgm" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvisvgm-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-fontware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-fontware-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-gregoriotex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-gregoriotex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-gsftopk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-gsftopk-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-kpathsea" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-kpathsea-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lacheck" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lacheck-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lcdftypetools" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lcdftypetools-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lib" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lib-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-lib-devel" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lib-devel-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-luatex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-luatex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-m-tx" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-m-tx-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-makeindex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-makeindex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-metafont" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-metafont-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-metapost" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-metapost-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-mflua" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mflua-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-mfware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mfware-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-musixtnt" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-musixtnt-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-omegaware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-omegaware-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-patgen" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-patgen-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pdftex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdftex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pdftools" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdftools-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pmx" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pmx-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ps2pk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ps2pk-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-pstools" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pstools-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ptex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ptex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-seetexk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-seetexk-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-synctex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-synctex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tex4ht" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tex4ht-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-texware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texware-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-tie" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tie-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-ttfutils" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ttfutils-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-uptex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-uptex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-velthuis" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-velthuis-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-vlna" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-vlna-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-web" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-web-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-xdvi" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-xdvi-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="texlive-xetex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-xetex-20180414-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-a2ping" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-a2ping-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-accfonts" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-accfonts-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-adhocfilelist" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-adhocfilelist-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-amstex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-amstex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-arara" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-arara-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-authorindex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-authorindex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bib2gls" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bib2gls-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bibexport" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bibexport-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-bundledoc" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bundledoc-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cachepic" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-cachepic-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-checkcites" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-checkcites-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-checklistings" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-checklistings-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-context" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-context-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-convbkmk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-convbkmk-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-crossrefware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-crossrefware-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cslatex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-cslatex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-csplain" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-csplain-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ctan-o-mat" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ctan-o-mat-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ctanify" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ctanify-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-ctanupload" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ctanupload-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-cyrillic" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-cyrillic-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-de-macro" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-de-macro-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-diadia" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-diadia-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dosepsbin" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dosepsbin-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dtxgen" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dtxgen-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dviasm" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dviasm-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-dviinfox" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dviinfox-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ebong" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ebong-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-eplain" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-eplain-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-epspdf" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-epspdf-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-epstopdf" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-epstopdf-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-exceltex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-exceltex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fig4latex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-fig4latex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-findhyph" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-findhyph-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fontinst" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-fontinst-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fontools" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-fontools-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-fragmaster" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-fragmaster-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-getmap" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-getmap-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-glossaries" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-glossaries-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-glyphlist" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-glyphlist-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-installfont" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-installfont-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-jadetex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-jadetex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-jfmutil" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-jfmutil-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-kotex-utils" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-kotex-utils-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-l3build" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-l3build-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex-git-log" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latex-git-log-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex-papersize" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latex-papersize-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex2man" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latex2man-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latex2nemeth" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latex2nemeth-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexdiff" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latexdiff-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexfileversion" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latexfileversion-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="texlive-latexindent" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latexindent-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-latexpand" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-latexpand-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lilyglyphs" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lilyglyphs-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-listbib" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-listbib-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-listings-ext" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-listings-ext-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lollipop" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lollipop-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ltxfileinfo" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ltxfileinfo-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ltximg" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ltximg-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lua2dox" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lua2dox-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-luaotfload" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-luaotfload-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lwarp" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lwarp-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-lyluatex" release="38.oe2203sp1" version="svn47584">
                         <filename>texlive-lyluatex-svn47584-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-make4ht" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-make4ht-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-makedtx" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-makedtx-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-match_parens" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-match_parens-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mathspic" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mathspic-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mf2pt1" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mf2pt1-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkgrkindex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mkgrkindex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkjobtexmf" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mkjobtexmf-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mkpic" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mkpic-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mltex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mltex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-mptopdf" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mptopdf-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-multibibliography" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-multibibliography-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-musixtex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-musixtex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-oberdiek" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-oberdiek-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pax" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pax-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfbook2" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdfbook2-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfcrop" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdfcrop-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfjam" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdfjam-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdflatexpicscale" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdflatexpicscale-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pdfxup" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdfxup-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pedigree-perl" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pedigree-perl-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-perltex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-perltex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-petri-nets" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-petri-nets-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pfarrei" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pfarrei-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pkfix" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pkfix-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pkfix-helper" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pkfix-helper-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pmxchords" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pmxchords-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pst-pdf" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pst-pdf-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pst2pdf" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pst2pdf-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ptex-fontmaps" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ptex-fontmaps-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ptex2pdf" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ptex2pdf-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-purifyeps" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-purifyeps-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pygmentex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pygmentex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-pythontex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pythontex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-rubik" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-rubik-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-splitindex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-splitindex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-srcredact" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-srcredact-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-sty2dtx" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-sty2dtx-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-svn-multi" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-svn-multi-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tetex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tetex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tex4ebook" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tex4ebook-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texconfig" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texconfig-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texcount" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texcount-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdef" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texdef-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdiff" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texdiff-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdirflatten" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texdirflatten-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdoc" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texdoc-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texdoctk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texdoctk-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texfot" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texfot-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive-en" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texlive-en-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive-scripts" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texlive-scripts-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texlive.infra" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texlive.infra-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texliveonfly" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texliveonfly-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texloganalyser" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texloganalyser-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texosquery" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texosquery-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-texsis" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texsis-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-thumbpdf" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-thumbpdf-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-tpic2pdftex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tpic2pdftex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-typeoutfileinfo" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-typeoutfileinfo-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-ulqda" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ulqda-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-urlbst" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-urlbst-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-vpe" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-vpe-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-wordcount" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-wordcount-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-xmltex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-xmltex-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="noarch" name="texlive-yplan" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-yplan-20180414-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-afm2pl" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-afm2pl-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-aleph" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-aleph-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-autosp" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-autosp-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-axodraw2" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-axodraw2-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-base-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base-debuginfo" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-base-debuginfo-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-base-debugsource" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-base-debugsource-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bibtex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtex8" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bibtex8-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-bibtexu" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-bibtexu-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-chktex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-chktex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-cjkutils" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-cjkutils-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ctie" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ctie-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-cweb" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-cweb-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-detex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-detex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dtl" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dtl-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvi2tty" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvi2tty-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvicopy" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvicopy-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvidvi" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvidvi-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dviljk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dviljk-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipdfmx" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvipdfmx-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipng" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvipng-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvipos" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvipos-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvips" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvips-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-dvisvgm" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-dvisvgm-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-fontware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-fontware-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-gregoriotex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-gregoriotex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-gsftopk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-gsftopk-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-kpathsea" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-kpathsea-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lacheck" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lacheck-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lcdftypetools" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lcdftypetools-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lib" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lib-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-lib-devel" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-lib-devel-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-luatex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-luatex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-m-tx" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-m-tx-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-makeindex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-makeindex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-metafont" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-metafont-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-metapost" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-metapost-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-mflua" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mflua-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-mfware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-mfware-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-musixtnt" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-musixtnt-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-omegaware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-omegaware-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-patgen" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-patgen-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pdftex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdftex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pdftools" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pdftools-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pmx" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pmx-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ps2pk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ps2pk-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-pstools" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-pstools-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ptex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ptex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-seetexk" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-seetexk-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-synctex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-synctex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tex4ht" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tex4ht-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-texware" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-texware-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-tie" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-tie-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-ttfutils" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-ttfutils-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-uptex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-uptex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-velthuis" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-velthuis-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-vlna" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-vlna-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-web" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-web-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-xdvi" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-xdvi-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="texlive-xetex" release="38.oe2203sp1" version="20180414">
                         <filename>texlive-xetex-20180414-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2004</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-08-16"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38875" id="CVE-2024-38875" title="CVE-2024-38875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39329" id="CVE-2024-39329" title="CVE-2024-39329" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39330" id="CVE-2024-39330" title="CVE-2024-39330" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39614" id="CVE-2024-39614" title="CVE-2024-39614" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41989" id="CVE-2024-41989" title="CVE-2024-41989" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41990" id="CVE-2024-41990" title="CVE-2024-41990" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41991" id="CVE-2024-41991" title="CVE-2024-41991" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42005" id="CVE-2024-42005" title="CVE-2024-42005" type="cve"></reference>
          </references>
          <description>An issue was discovered in Django 4.2 before 4.2.14 and 5.0 before 5.0.7. urlize and urlizetrunc were subject to a potential denial of service attack via certain inputs with a very large number of brackets.(CVE-2024-38875)An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. The django.contrib.auth.backends.ModelBackend.authenticate() method allows remote attackers to enumerate users via a timing attack involving login requests for users with an unusable password.(CVE-2024-39329)An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. Derived classes of the django.core.files.storage.Storage base class, when they override generate_filename() without replicating the file-path validations from the parent class, potentially allow directory traversal via certain inputs during a save() call. (Built-in Storage sub-classes are unaffected.)(CVE-2024-39330)An issue was discovered in Django 5.0 before 5.0.7 and 4.2 before 4.2.14. get_supported_language_variant() was subject to a potential denial-of-service attack when used with very long strings containing specific characters.(CVE-2024-39614)An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The floatformat template filter is subject to significant memory consumption when given a string representation of a number in scientific notation with a large exponent.(CVE-2024-41989)An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The urlize() and urlizetrunc() template filters are subject to a potential denial-of-service attack via very large inputs with a specific sequence of characters.(CVE-2024-41990)An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. The urlize and urlizetrunc template filters, and the AdminURLFieldWidget widget, are subject to a potential denial-of-service attack via certain inputs with a very large number of Unicode characters.(CVE-2024-41991)An issue was discovered in Django 5.0 before 5.0.8 and 4.2 before 4.2.15. QuerySet.values() and values_list() methods on models with a JSONField are subject to SQL injection in column aliases via a crafted JSON object key as a passed *arg.(CVE-2024-42005)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="1.oe2203sp1" version="4.2.15">
                         <filename>python-django-help-4.2.15-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="1.oe2203sp1" version="4.2.15">
                         <filename>python3-Django-4.2.15-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2005</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21125" id="CVE-2024-21125" title="CVE-2024-21125" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21142" id="CVE-2024-21142" title="CVE-2024-21142" type="cve"></reference>
          </references>
          <description>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-21125)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-21142)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2009</id>
          <title>An update for dovecot is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23184" id="CVE-2024-23184" title="CVE-2024-23184" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23185" id="CVE-2024-23185" title="CVE-2024-23185" type="cve"></reference>
          </references>
          <description>(CVE-2024-23184)(CVE-2024-23185)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="dovecot" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-2.3.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dovecot-debuginfo" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-debuginfo-2.3.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dovecot-debugsource" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-debugsource-2.3.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dovecot-devel" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-devel-2.3.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="dovecot-help" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-help-2.3.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dovecot" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-2.3.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dovecot-debuginfo" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-debuginfo-2.3.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dovecot-debugsource" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-debugsource-2.3.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dovecot-devel" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-devel-2.3.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="dovecot-help" release="6.oe2203sp1" version="2.3.15">
                         <filename>dovecot-help-2.3.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2011</id>
          <title>An update for libvirt is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2496" id="CVE-2024-2496" title="CVE-2024-2496" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-2496)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libvirt" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-admin" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-admin-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-bash-completion" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-bash-completion-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-client" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-client-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-config-network" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-network-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-config-nwfilter" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-nwfilter-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-interface" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-interface-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-network" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-network-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-nodedev" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nodedev-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-nwfilter" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nwfilter-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-qemu" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-qemu-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-secret" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-secret-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-core" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-core-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-disk" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-disk-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-gluster" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-gluster-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-iscsi" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-iscsi-direct" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-logical" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-logical-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-mpath" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-mpath-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-rbd" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-rbd-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-driver-storage-scsi" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-scsi-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-kvm" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-kvm-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-daemon-qemu" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-qemu-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-debuginfo" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debuginfo-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-debugsource" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debugsource-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-devel" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-devel-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-docs" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-docs-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-libs" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-libs-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-lock-sanlock" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-lock-sanlock-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-nss" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-nss-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libvirt-wireshark" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-wireshark-6.2.0-65.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-admin" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-admin-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-bash-completion" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-bash-completion-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-client" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-client-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-config-network" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-network-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-config-nwfilter" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-config-nwfilter-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-interface" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-interface-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-network" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-network-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-nodedev" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nodedev-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-nwfilter" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-nwfilter-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-qemu" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-qemu-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-secret" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-secret-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-core" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-core-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-disk" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-disk-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-gluster" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-gluster-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-iscsi" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-iscsi-direct" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-iscsi-direct-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-logical" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-logical-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-mpath" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-mpath-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-rbd" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-rbd-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-driver-storage-scsi" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-driver-storage-scsi-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-kvm" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-kvm-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-daemon-qemu" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-daemon-qemu-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-debuginfo" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debuginfo-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-debugsource" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-debugsource-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-devel" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-devel-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-docs" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-docs-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-libs" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-libs-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-lock-sanlock" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-lock-sanlock-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-nss" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-nss-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libvirt-wireshark" release="65.oe2203sp1" version="6.2.0">
                         <filename>libvirt-wireshark-6.2.0-65.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2015</id>
          <title>An update for bind is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-50868" id="CVE-2023-50868" title="CVE-2023-50868" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0760" id="CVE-2024-0760" title="CVE-2024-0760" type="cve"></reference>
          </references>
          <description>The Closest Encloser Proof aspect of the DNS protocol (in RFC 5155 when RFC 9276 guidance is skipped) allows remote attackers to cause a denial of service (CPU consumption for SHA-1 computations) via DNSSEC responses in a random subdomain attack, aka the &#34;NSEC3&#34; issue. The RFC 5155 specification implies that an algorithm must perform thousands of iterations of a hash function in certain situations.(CVE-2023-50868)A malicious client can send many DNS messages over TCP, potentially causing the server to become unstable while the attack is in progress. The server may recover after the attack ceases. Use of ACLs will not mitigate the attack. This issue affects BIND 9 versions 9.18.1 through 9.18.27, 9.19.0 through 9.19.24, and 9.18.11-S1 through 9.18.27-S1.(CVE-2024-0760)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="32" arch="aarch64" name="bind" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-chroot" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debuginfo" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-debugsource" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-devel" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-dnssec-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-libs" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-devel" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-libs" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-pkcs11-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="aarch64" name="bind-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-23.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-dnssec-doc" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-doc-9.16.23-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="bind-license" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-license-9.16.23-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="noarch" name="python3-bind" release="23.oe2203sp1" version="9.16.23">
                         <filename>python3-bind-9.16.23-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-chroot" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-chroot-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debuginfo" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-debuginfo-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-debugsource" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-debugsource-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-devel" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-devel-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-dnssec-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-dnssec-utils-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-libs" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-libs-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-devel" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-devel-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-libs" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-libs-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-pkcs11-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-pkcs11-utils-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="32" arch="x86_64" name="bind-utils" release="23.oe2203sp1" version="9.16.23">
                         <filename>bind-utils-9.16.23-23.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2019</id>
          <title>An update for c-ares is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25629" id="CVE-2024-25629" title="CVE-2024-25629" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-25629)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="c-ares" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-debuginfo" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-debugsource" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="c-ares-devel" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="c-ares-help" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-help-1.18.1-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-1.18.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debuginfo" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debuginfo-1.18.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-debugsource" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-debugsource-1.18.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="c-ares-devel" release="8.oe2203sp1" version="1.18.1">
                         <filename>c-ares-devel-1.18.1-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2024</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-36763" id="CVE-2022-36763" title="CVE-2022-36763" type="cve"></reference>
          </references>
          <description>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-36763)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="19.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="19.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="19.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-19.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="19.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="19.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="19.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="19.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-19.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="19.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="19.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="19.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-19.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2025</id>
          <title>An update for unbound is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43167" id="CVE-2024-43167" title="CVE-2024-43167" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43168" id="CVE-2024-43168" title="CVE-2024-43168" type="cve"></reference>
          </references>
          <description>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-43167)A heap-buffer-overflow flaw was found in the cfg_mark_ports function within Unbound&#39;s config_file.c, which can lead to memory corruption. This issue could allow an attacker with local access to provide specially crafted input, potentially causing the application to crash or allowing arbitrary code execution. This could result in a denial of service or unauthorized actions on the system.(CVE-2024-43168)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-unbound" release="12.oe2203sp1" version="1.13.2">
                         <filename>python3-unbound-1.13.2-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-1.13.2-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debuginfo" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debugsource" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-devel" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-devel-1.13.2-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-help" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-help-1.13.2-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-libs" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-libs-1.13.2-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unbound" release="12.oe2203sp1" version="1.13.2">
                         <filename>python3-unbound-1.13.2-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-1.13.2-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debuginfo" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debugsource" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-devel" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-devel-1.13.2-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-help" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-help-1.13.2-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-libs" release="12.oe2203sp1" version="1.13.2">
                         <filename>unbound-libs-1.13.2-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2026</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43374" id="CVE-2024-43374" title="CVE-2024-43374" type="cve"></reference>
          </references>
          <description>The UNIX editor Vim prior to version 9.1.0678 has a use-after-free error in argument list handling. When adding a new file to the argument list, this triggers `Buf*` autocommands. If in such an autocommand the buffer that was just opened is closed (including the window where it is shown), this causes the window structure to be freed which contains a reference to the argument list that we are actually modifying. Once the autocommands are completed, the references to the window and argument list are no longer valid and as such cause an use-after-free. Impact is low since the user must either intentionally add some unusual autocommands that wipe a buffer during creation (either manually or by sourcing a malicious plugin), but it will crash Vim. The issue has been fixed as of Vim patch v9.1.0678.(CVE-2024-43374)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="vim-X11" release="25.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-common" release="25.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-debuginfo" release="25.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-debugsource" release="25.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-enhanced" release="25.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="vim-minimal" release="25.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-25.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="vim-filesystem" release="25.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-25.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-X11" release="25.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-common" release="25.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-debuginfo" release="25.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-debugsource" release="25.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-enhanced" release="25.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="vim-minimal" release="25.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-25.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2031</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26586" id="CVE-2024-26586" title="CVE-2024-26586" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-26598" id="CVE-2024-26598" title="CVE-2024-26598" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36484" id="CVE-2024-36484" title="CVE-2024-36484" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36880" id="CVE-2024-36880" title="CVE-2024-36880" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36900" id="CVE-2024-36900" title="CVE-2024-36900" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36904" id="CVE-2024-36904" title="CVE-2024-36904" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36914" id="CVE-2024-36914" title="CVE-2024-36914" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36933" id="CVE-2024-36933" title="CVE-2024-36933" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36938" id="CVE-2024-36938" title="CVE-2024-36938" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38544" id="CVE-2024-38544" title="CVE-2024-38544" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38597" id="CVE-2024-38597" title="CVE-2024-38597" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39276" id="CVE-2024-39276" title="CVE-2024-39276" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40902" id="CVE-2024-40902" title="CVE-2024-40902" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40966" id="CVE-2024-40966" title="CVE-2024-40966" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41066" id="CVE-2024-41066" title="CVE-2024-41066" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41073" id="CVE-2024-41073" title="CVE-2024-41073" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41087" id="CVE-2024-41087" title="CVE-2024-41087" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41088" id="CVE-2024-41088" title="CVE-2024-41088" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42070" id="CVE-2024-42070" title="CVE-2024-42070" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42126" id="CVE-2024-42126" title="CVE-2024-42126" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42127" id="CVE-2024-42127" title="CVE-2024-42127" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42131" id="CVE-2024-42131" title="CVE-2024-42131" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42232" id="CVE-2024-42232" title="CVE-2024-42232" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42236" id="CVE-2024-42236" title="CVE-2024-42236" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42304" id="CVE-2024-42304" title="CVE-2024-42304" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42310" id="CVE-2024-42310" title="CVE-2024-42310" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43839" id="CVE-2024-43839" title="CVE-2024-43839" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:mlxsw: spectrum_acl_tcam: Fix stack corruptionWhen tc filters are first added to a net device, the corresponding localport gets bound to an ACL group in the device. The group contains a listof ACLs. In turn, each ACL points to a different TCAM region where thefilters are stored. During forwarding, the ACLs are sequentiallyevaluated until a match is found.One reason to place filters in different regions is when they are addedwith decreasing priorities and in an alternating order so that twoconsecutive filters can never fit in the same region because of theirkey usage.In Spectrum-2 and newer ASICs the firmware started to report that themaximum number of ACLs in a group is more than 16, but the layout of theregister that configures ACL groups (PAGT) was not updated to accountfor that. It is therefore possible to hit stack corruption [1] in therare case where more than 16 ACLs in a group are required.Fix by limiting the maximum ACL group size to the minimum between whatthe 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 thiscondition 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-2024-26586)In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: vgic-its: Avoid potential UAF in LPI translation cacheThere is a potential UAF scenario in the case of an LPI translationcache hit racing with an operation that invalidates the cache, suchas a DISCARD ITS command. The root of the problem is thatvgic_its_check_cache() does not elevate the refcount on the vgic_irqbefore dropping the lock that serializes refcount changes.Have vgic_its_check_cache() raise the refcount on the returned vgic_irqand add the corresponding decrement after queueing the interrupt.(CVE-2024-26598)In the Linux kernel, the following vulnerability has been resolved:net: relax socket state check at accept time.Christoph reported the following splat:WARNING: CPU: 1 PID: 772 at net/ipv4/af_inet.c:761 __inet_accept+0x1f4/0x4a0Modules linked in:CPU: 1 PID: 772 Comm: syz-executor510 Not tainted 6.9.0-rc7-g7da7119fe22b #56Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.11.0-2.el7 04/01/2014RIP: 0010:__inet_accept+0x1f4/0x4a0 net/ipv4/af_inet.c:759Code: 04 38 84 c0 0f 85 87 00 00 00 41 c7 04 24 03 00 00 00 48 83 c4 10 5b 41 5c 41 5d 41 5e 41 5f 5d c3 cc cc cc cc e8 ec b7 da fd &lt;0f&gt; 0b e9 7f fe ff ff e8 e0 b7 da fd 0f 0b e9 fe fe ff ff 89 d9 80RSP: 0018:ffffc90000c2fc58 EFLAGS: 00010293RAX: ffffffff836bdd14 RBX: 0000000000000000 RCX: ffff888104668000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: dffffc0000000000 R08: ffffffff836bdb89 R09: fffff52000185f64R10: dffffc0000000000 R11: fffff52000185f64 R12: dffffc0000000000R13: 1ffff92000185f98 R14: ffff88810754d880 R15: ffff8881007b7800FS:  000000001c772880(0000) GS:ffff88811b280000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007fb9fcf2e178 CR3: 00000001045d2002 CR4: 0000000000770ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: &lt;TASK&gt; inet_accept+0x138/0x1d0 net/ipv4/af_inet.c:786 do_accept+0x435/0x620 net/socket.c:1929 __sys_accept4_file net/socket.c:1969 [inline] __sys_accept4+0x9b/0x110 net/socket.c:1999 __do_sys_accept net/socket.c:2016 [inline] __se_sys_accept net/socket.c:2013 [inline] __x64_sys_accept+0x7d/0x90 net/socket.c:2013 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0x58/0x100 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x4315f9Code: fd ff 48 81 c4 80 00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 0f 83 ab b4 fd ff c3 66 2e 0f 1f 84 00 00 00 00RSP: 002b:00007ffdb26d9c78 EFLAGS: 00000246 ORIG_RAX: 000000000000002bRAX: ffffffffffffffda RBX: 0000000000400300 RCX: 00000000004315f9RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000004RBP: 00000000006e1018 R08: 0000000000400300 R09: 0000000000400300R10: 0000000000400300 R11: 0000000000000246 R12: 0000000000000000R13: 000000000040cdf0 R14: 000000000040ce80 R15: 0000000000000055 &lt;/TASK&gt;The reproducer invokes shutdown() before entering the listener status.After commit 94062790aedb (&#34;tcp: defer shutdown(SEND_SHUTDOWN) forTCP_SYN_RECV sockets&#34;), the above causes the child to reach the acceptsyscall in FIN_WAIT1 status.Eric noted we can relax the existing assertion in __inet_accept()(CVE-2024-36484)In the Linux kernel, the following vulnerability has been resolved:Bluetooth: qca: add missing firmware sanity checksAdd the missing sanity checks when parsing the firmware files beforedownloading them to avoid accessing and corrupting memory beyond thevmalloced buffer.(CVE-2024-36880)In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix kernel crash when devlink reload during initializationThe 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 kernelcrash.This patch fixes this by registering the devlink afterhardware initialization.(CVE-2024-36900)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 (&#34;tcp/dccp: avoid one atomic operation fortimewait hashdance&#34;), inet_twsk_hashdance() sets TIME-WAIT socket&#39;ssk_refcnt after putting it into ehash and releasing the bucket lock.Thus, there is a small race window where other threads could try toreuse 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 overwrittenand sock_put() will cause underflow, triggering a real use-after-freesomewhere else.To avoid the use-after-free, we need to use refcount_inc_not_zero() intcp_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/0x110CPU: 0 PID: 1039313 Comm: trigger Not tainted 6.8.6-200.fc39.x86_64 #1Hardware name: VMware, Inc. VMware20,1/440BX Desktop Reference Platform, BIOS VMW201.00V.21805430.B64.2305221830 05/22/2023RIP: 0010:refcount_warn_saturate+0xe5/0x110Code: 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 e8RSP: 0018:ffffc90006b43b60 EFLAGS: 00010282RAX: 0000000000000000 RBX: ffff888009bb3ef0 RCX: 0000000000000027RDX: ffff88807be218c8 RSI: 0000000000000001 RDI: ffff88807be218c0RBP: 0000000000069d70 R08: 0000000000000000 R09: ffffc90006b439f0R10: ffffc90006b439e8 R11: 0000000000000003 R12: ffff8880029ede84R13: 0000000000004e20 R14: ffffffff84356dc0 R15: ffff888009bb3ef0FS:  00007f62c10926c0(0000) GS:ffff88807be00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000020ccb000 CR3: 000000004628c005 CR4: 0000000000f70ef0PKRU: 55555554Call 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/0x80RIP: 0033:0x7f62c11a885dCode: 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 48RSP: 002b:00007f62c1091e58 EFLAGS: 00000296 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 0000000020ccb004 RCX: 00007f62c11a885dRDX: 0000000000000010 RSI: 0000000020ccb000 RDI: 0000000000000003RBP: 00007f62c1091e90 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000296 R12: 00007f62c10926c0R13: ffffffffffffff88 R14: 0000000000000000 R15: 00007ffe237885b0 &lt;/TASK&gt;(CVE-2024-36904)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip on writeback when it&#39;s not applicable[WHY]dynamic memory safety error detector (KASAN) catches and generates errormessages &#34;BUG: KASAN: slab-out-of-bounds&#34; as writeback connector does notsupport certain features which are not initialized.[HOW]Skip them when connector type is DRM_MODE_CONNECTOR_WRITEBACK.(CVE-2024-36914)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 GSOpacket of VIRTIO_NET_HDR_GSO_UDP layering the following protocols:  ETH_P_8021AD + ETH_P_NSH + ETH_P_IPV6 + IPPROTO_UDPNSH can encapsulate IPv4, IPv6, Ethernet, NSH, and MPLS.  As the innerprotocol can be Ethernet, NSH GSO handler, nsh_gso_segment(), callsskb_mac_gso_segment() to invoke inner protocol GSO handlers.nsh_gso_segment() does the following for the original skb beforecalling 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_lenThere 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 forthe segmented skb, instead of the NSH header.To do that, let&#39;s calculate the outer header position relatively fromthe 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/0x6bUninit 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-36933)In the Linux kernel, the following vulnerability has been resolved:bpf, skmsg: Fix NULL pointer dereference in sk_psock_skb_ingress_enqueueFix NULL pointer data-races in sk_psock_skb_ingress_enqueue() whichsyzbot reported [1].[1]BUG: KCSAN: data-race in sk_psock_drop / sk_psock_skb_ingress_enqueuewrite 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/0x75read 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/0x75value changed: 0xffffffff83d7feb0 -&gt; 0x0000000000000000Reported by Kernel Concurrency Sanitizer on:CPU: 0 PID: 10713 Comm: syz-executor.4 Tainted: G        W          6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/29/2024Prior to this, commit 4cd12c6065df (&#34;bpf, sockmap: Fix NULL pointerdereference in sk_psock_verdict_data_ready()&#34;) fixed one NULL pointersimilarly due to no protection of saved_data_ready. Here is anotherdifferent caller causing the same issue because of the same reason. Sowe should protect it with sk_callback_lock read lock because the writerside in the sk_psock_drop() uses &#34;write_lock_bh(&amp;sk-&gt;sk_callback_lock);&#34;.To avoid errors that could happen in future, I move those two pairs oflock into the sk_psock_data_ready(), which is suggested by John Fastabend.(CVE-2024-36938)In the Linux kernel, the following vulnerability has been resolved:RDMA/rxe: Fix seg fault in rxe_comp_queue_pktIn rxe_comp_queue_pkt() an incoming response packet skb is enqueued to theresp_pkts queue and then a decision is made whether to run the completertask inline or schedule it. Finally the skb is dereferenced to bump a &#39;hw&#39;performance counter. This is wrong because if the completer task isalready running in a separate thread it may have already processed the skband freed it which can cause a seg fault.  This has been observedinfrequently in testing at high scale.This patch fixes this by changing the order of enqueuing the packet untilafter the counter is accessed.(CVE-2024-38544)In the Linux kernel, the following vulnerability has been resolved:eth: sungem: remove .ndo_poll_controller to avoid deadlocksErhard 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/0x20cgem_poll_controller() disables interrupts, which may sleep.We can&#39;t sleep in netpoll, it has interrupts disabled completely.Strangely, gem_poll_controller() doesn&#39;t even poll the completions,and instead acts as if an interrupt has fired so it just schedulesNAPI and exits. None of this has been necessary for years, sincenetpoll invokes NAPI directly.(CVE-2024-38597)In the Linux kernel, the following vulnerability has been resolved:ext4: fix mb_cache_entry&#39;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/0x290Modules linked in:CPU: 0 PID: 5075 Comm: syz-executor199 Not tainted 6.9.0-rc6-gb947cc5bf6d7RIP: 0010:mb_cache_destroy+0x224/0x290 fs/mbcache.c:419Call 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(), ifext4_sb_bread() returns -ENOMEM, the ce&#39;s e_refcnt, which has already grownin the __entry_find(), won&#39;t be put away, and eventually trigger the aboveissue 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-39276)In the Linux kernel, the following vulnerability has been resolved:jfs: xattr: fix buffer overflow for invalid xattrWhen an xattr size is not what is expected, it is printed out to thekernel log in hex format as a form of debugging.  But when that xattrsize is bigger than the expected size, printing it out can cause anaccess off the end of the buffer.Fix this all up by properly restricting the size of the debug hex dumpin the kernel log.(CVE-2024-40902)In the Linux kernel, the following vulnerability has been resolved:tty: add the option to have a tty reject a new ldisc... and use it to limit the virtual terminals to just N_TTY.  They arekind of special, and in particular, the &#34;con_write()&#34; routine violatesthe &#34;writes cannot sleep&#34; rule that some ldiscs rely on.This avoids the   BUG: sleeping function called from invalid context at kernel/printk/printk.c:2659when N_GSM has been attached to a virtual console, and gsmld_write()calls con_write() while holding a spinlock, and con_write() then triesto get the console lock.(CVE-2024-40966)In the Linux kernel, the following vulnerability has been resolved:ibmvnic: Add tx check to prevent skb leakBelow is a summary of how the driver stores a reference to an skb duringtransmit:    tx_buff[free_map[consumer_index]]-&gt;skb = new_skb;    free_map[consumer_index] = IBMVNIC_INVALID_MAP;    consumer_index ++;Where variable data looks like this:    free_map == [4, IBMVNIC_INVALID_MAP, IBMVNIC_INVALID_MAP, 0, 3]                                               &#x9;consumer_index^    tx_buff == [skb=null, skb=&lt;ptr&gt;, skb=&lt;ptr&gt;, skb=null, skb=null]The driver has checks to ensure that free_map[consumer_index] pointed toa valid index but there was no check to ensure that this index pointedto an unused/null skb address. So, if, by some chance, our free_map andtx_buff lists become out of sync then we were previously risking anskb memory leak. This could then cause tcp congestion control to stopsending packets, eventually leading to ETIMEDOUT.Therefore, add a conditional to ensure that the skb address is null. Ifnot then warn the user (because this is still a bug that should bepatched) and free the old pointer to prevent memleak/tcp problems.(CVE-2024-41066)In the Linux kernel, the following vulnerability has been resolved:nvme: avoid double free special payloadIf a discard request needs to be retried, and that retry may fail beforea new special payload is added, a double free will result. Clear theRQF_SPECIAL_LOAD when the request is cleaned.(CVE-2024-41073)In the Linux kernel, the following vulnerability has been resolved:ata: libata-core: Fix double free on errorIf e.g. the ata_port_alloc() call in ata_host_alloc() fails, we will jumpto 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) inata_host_alloc() will lead to a double free:kernel BUG at mm/slub.c:553!Oops: invalid opcode: 0000 [#1] PREEMPT SMP NOPTICPU: 11 PID: 599 Comm: (udev-worker) Not tainted 6.10.0-rc5 #47Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014RIP: 0010:kfree+0x2cf/0x2f0Code: 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 daRSP: 0018:ffffc90000f377f0 EFLAGS: 00010246RAX: ffff888112b1f2c0 RBX: ffff888112b1f2c0 RCX: ffff888112b1f320RDX: 000000000000400b RSI: ffffffffc02c9de5 RDI: ffff888112b1f2c0RBP: ffffc90000f37830 R08: 0000000000000000 R09: 0000000000000000R10: ffffc90000f37610 R11: 617461203a736b6e R12: ffffea00044ac780R13: ffff888100046400 R14: ffffffffc02c9de5 R15: 0000000000000006FS:  00007f2f1cabe980(0000) GS:ffff88813b380000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f2f1c3acf75 CR3: 0000000111724000 CR4: 0000000000750ef0PKRU: 55555554Call 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-41087)In the Linux kernel, the following vulnerability has been resolved:can: mcp251xfd: fix infinite loop when xmit failsWhen the mcp251xfd_start_xmit() function fails, the driver stopsprocessing messages, and the interrupt routine does not return,running indefinitely even after killing the running application.Error messages:[  441.298819] mcp251xfd spi2.0 can0: ERROR in mcp251xfd_start_xmit: -16[  441.306498] mcp251xfd spi2.0 can0: Transmit Event FIFO buffer not empty. (seq=0x000017c7, tef_tail=0x000017cf, tef_head=0x000017d0, tx_head=0x000017d3).... and repeat forever.The issue can be triggered when multiple devices share the same SPIinterface. And there is concurrent access to the bus.The problem occurs because tx_ring-&gt;head increments even ifmcp251xfd_start_xmit() fails. Consequently, the driver skips one TXpackage while still expecting a response inmcp251xfd_handle_tefif_one().Resolve the issue by starting a workqueue to write the tx objsynchronously if err = -EBUSY. In case of another error, decrementtx_ring-&gt;head, remove skb from the echo stack, and drop the message.[mkl: use more imperative wording in patch description](CVE-2024-41088)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fully validate NFT_DATA_VALUE on store to data registersregister store validation for NFT_DATA_VALUE is conditional, however,the datatype is always either NFT_DATA_VALUE or NFT_DATA_VERDICT. Thisonly requires a new helper function to infer the register type from theset datatype so this conditional check can be removed. Otherwise,pointer to chain object can be leaked through the registers.(CVE-2024-42070)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 kernelcrash when invoked during real mode interrupt handling (e.g. early HMI/MCEinterrupt 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&#39;t see any issue whenpercpu allocation is from the embedded first chunk. However withCONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK enabled there are chances where percpuallocation can come from the vmalloc area.With kernel command line &#34;percpu_alloc=page&#34; we can force percpu allocationto 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/0x1f8Fix this by avoiding use of nmi_enter()/nmi_exit() in real mode if percpufirst chunk is not embedded.(CVE-2024-42126)In the Linux kernel, the following vulnerability has been resolved:drm/lima: fix shared irq handling on driver removelima uses a shared interrupt, so the interrupt handlers must be preparedto be called at any time. At driver removal time, the clocks aredisabled early and the interrupts stay registered until the very end ofthe remove process due to the devm usage.This is potentially a bug as the interrupts access device registerswhich assumes clocks are enabled. A crash can be triggered by removingthe driver in a kernel with CONFIG_DEBUG_SHIRQ enabled.This patch frees the interrupts at each lima device finishing callbackso that the handlers are already unregistered by the time we fullydisable clocks.(CVE-2024-42127)In the Linux kernel, the following vulnerability has been resolved:mm: avoid overflows in dirty throttling logicThe dirty throttling logic is interspersed with assumptions that dirtylimits in PAGE_SIZE units fit into 32-bit (so that various multiplicationsfit into 64-bits).  If limits end up being larger, we will hit overflows,possible divisions by 0 etc.  Fix these problems by never allowing solarge dirty limits as they have dubious practical value anyway.  Fordirty_bytes / dirty_background_bytes interfaces we can just refuse to setso large limits.  For dirty_ratio / dirty_background_ratio it isn&#39;t sosimple as the dirty limit is computed from the amount of available memorywhich can change due to memory hotplug etc.  So when converting dirtylimits from ratios to numbers of pages, we just don&#39;t allow the result toexceed UINT_MAX.This is root-only triggerable problem which occurs when the operatorsets dirty limits to &gt;16 TB.(CVE-2024-42131)In the Linux kernel, the following vulnerability has been resolved:libceph: fix race between delayed_work() and ceph_monc_stop()The way the delayed work is handled in ceph_monc_stop() is prone toraces with mon_fault() and possibly also finish_hunting().  Both ofthese can requeue the delayed work which wouldn&#39;t be canceled by any ofthe following code in case that happens after cancel_delayed_work_sync()runs -- __close_session() doesn&#39;t mess with the delayed work in orderto avoid interfering with the hunting interval logic.  This part wasmissed in commit b5d91704f53e (&#34;libceph: behave in mon_fault() ifcur_mon &lt; 0&#34;) and use-after-free can still ensue on monc and objectsthat hang off of it, with monc-&gt;auth and monc-&gt;monmap beingparticularly susceptible to quickly being reused.To fix this:- clear monc-&gt;cur_mon and monc-&gt;hunting as part of closing the session  in ceph_monc_stop()- bail from delayed_work() if monc-&gt;cur_mon is cleared, similar to how  it&#39;s done in mon_fault() and finish_hunting() (based on monc-&gt;hunting)- call cancel_delayed_work_sync() after the session is closed(CVE-2024-42232)In the Linux kernel, the following vulnerability has been resolved:usb: gadget: configfs: Prevent OOB read/write in usb_string_copy()Userspace provided string &#39;s&#39; could trivially have the length zero. Leftunchecked this will firstly result in an OOB read in the form`if (str[0 - 1] == &#39;\n&#39;) followed closely by an OOB write in the form`str[0 - 1] = &#39;\0&#39;`.There is already a validating check to catch strings that are too long.Let&#39;s supply an additional check for invalid strings that are too short.(CVE-2024-42236)In the Linux kernel, the following vulnerability has been resolved:ext4: make sure the first directory block is not a holeThe syzbot constructs a directory that has no dirblock but is non-inline,i.e. the first directory block is a hole. And no errors are reported whencreating files in this directory in the following flow.    ext4_mknod     ...      ext4_add_entry        // Read block 0        ext4_read_dirblock(dir, block, DIRENT)          bh = ext4_bread(NULL, inode, block, 0)          if (!bh &amp;&amp; (type == INDEX || type == DIRENT_HTREE))          // The first directory block is a hole          // But type == DIRENT, so no error is reported.After that, we get a directory block without &#39;.&#39; and &#39;..&#39; but with a validdentry. This may cause some code that relies on dot or dotdot (such asmake_indexed_dir()) to crash.Therefore when ext4_read_dirblock() finds that the first directory blockis a hole report that the filesystem is corrupted and return an error toavoid loading corrupted data from disk causing something bad.(CVE-2024-42304)In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in cdv_intel_lvds_get_modesIn cdv_intel_lvds_get_modes(), the return value of drm_mode_duplicate()is assigned to mode, which will lead to a NULL pointer dereference onfailure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42310)In the Linux kernel, the following vulnerability has been resolved:bna: adjust &#39;name&#39; buf size of bna_tcb and bna_ccb structuresTo have enough space to write all possible sprintf() args. Currently&#39;name&#39; size is 16, but the first &#39;%s&#39; specifier may already need atleast 16 characters, since &#39;bnad-&gt;netdev-&gt;name&#39; is used there.For &#39;%d&#39; specifiers, assume that they require: * 1 char for &#39;tx_id + tx_info-&gt;tcb[i]-&gt;id&#39; sum, BNAD_MAX_TXQ_PER_TX is 8 * 2 chars for &#39;rx_id + rx_info-&gt;rx_ctrl[i].ccb-&gt;id&#39;, BNAD_MAX_RXP_PER_RX   is 16And replace sprintf with snprintf.Detected using the static analysis tool - Svace.(CVE-2024-43839)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.90.0.171.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.90.0.171.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2032</id>
          <title>An update for rubygem-rack is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44570" id="CVE-2022-44570" title="CVE-2022-44570" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-44571" id="CVE-2022-44571" title="CVE-2022-44571" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25126" id="CVE-2024-25126" title="CVE-2024-25126" type="cve"></reference>
          </references>
          <description>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-44570)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-44571)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-25126)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="noarch" name="rubygem-rack" release="4.oe2203sp1" version="2.2.3.1">
                         <filename>rubygem-rack-2.2.3.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="rubygem-rack-help" release="4.oe2203sp1" version="2.2.3.1">
                         <filename>rubygem-rack-help-2.2.3.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2038</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41946" id="CVE-2024-41946" title="CVE-2024-41946" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-41946)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="137.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="137.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="137.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="137.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="137.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-137.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="137.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="137.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="137.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="137.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="137.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="137.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="137.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="137.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="137.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="137.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="137.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="137.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-137.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="137.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="137.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="137.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="137.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="137.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="137.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-137.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2039</id>
          <title>An update for gdk-pixbuf2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48622" id="CVE-2022-48622" title="CVE-2022-48622" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-48622)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gdk-pixbuf2" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-2.42.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-debuginfo" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-debuginfo-2.42.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-debugsource" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-debugsource-2.42.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-devel" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-devel-2.42.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-modules" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-modules-2.42.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gdk-pixbuf2-tests" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-tests-2.42.6-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gdk-pixbuf2-help" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-help-2.42.6-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-2.42.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-debuginfo" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-debuginfo-2.42.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-debugsource" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-debugsource-2.42.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-devel" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-devel-2.42.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-modules" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-modules-2.42.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gdk-pixbuf2-tests" release="7.oe2203sp1" version="2.42.6">
                         <filename>gdk-pixbuf2-tests-2.42.6-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2042</id>
          <title>An update for xorg-x11-server-xwayland is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6377" id="CVE-2023-6377" title="CVE-2023-6377" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31083" id="CVE-2024-31083" title="CVE-2024-31083" type="cve"></reference>
          </references>
          <description>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-6377)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-31083)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debuginfo" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-debugsource" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xwayland-devel" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-22.1.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debuginfo" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debuginfo-22.1.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-debugsource" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-debugsource-22.1.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xwayland-devel" release="6.oe2203sp1" version="22.1.2">
                         <filename>xorg-x11-server-Xwayland-devel-22.1.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2043</id>
          <title>An update for python-webob is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42353" id="CVE-2024-42353" title="CVE-2024-42353" type="cve"></reference>
          </references>
          <description>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&#39;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.(CVE-2024-42353)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python3-webob" release="3.oe2203sp1" version="1.8.7">
                         <filename>python3-webob-1.8.7-3.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2046</id>
          <title>An update for libtiff is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7006" id="CVE-2024-7006" title="CVE-2024-7006" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-7006)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libtiff" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debuginfo" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-debugsource" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-devel" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-static" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libtiff-tools" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-38.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libtiff-help" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-help-4.3.0-38.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-4.3.0-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debuginfo" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debuginfo-4.3.0-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-debugsource" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-debugsource-4.3.0-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-devel" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-devel-4.3.0-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-static" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-static-4.3.0-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libtiff-tools" release="38.oe2203sp1" version="4.3.0">
                         <filename>libtiff-tools-4.3.0-38.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2051</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38473" id="CVE-2024-38473" title="CVE-2024-38473" type="cve"></reference>
          </references>
          <description>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-38473)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="httpd" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-help-2.4.51-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2053</id>
          <title>An update for flatpak is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42472" id="CVE-2024-42472" title="CVE-2024-42472" type="cve"></reference>
          </references>
          <description>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&#39;t have access to the real user home directory will see an empty home directory with a writeable subdirectory `subdir`. Behind the scenes, this directory is actually a bind mount and the data is stored in the per-application directory as `~/.var/app/$APPID/subdir`. This allows existing apps that are not aware of the per-application directory to still work as intended without general home directory access.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 &#34;wrap&#34; subproject, which has been updated to 0.10.0. The 1.12.x and 1.10.x branches will not be updated for this vulnerability. Long-term support OS distributions should backport the individual changes into their versions of Flatpak and bubblewrap, or update to newer versions if their stability policy allows it. As a workaround, avoid using applications using the `persistent` (`--persist`) permission.(CVE-2024-42472)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="flatpak" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-1.10.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-debuginfo" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debuginfo-1.10.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-debugsource" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debugsource-1.10.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="flatpak-devel" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-devel-1.10.2-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="flatpak-help" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-help-1.10.2-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-1.10.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-debuginfo" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debuginfo-1.10.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-debugsource" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-debugsource-1.10.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="flatpak-devel" release="9.oe2203sp1" version="1.10.2">
                         <filename>flatpak-devel-1.10.2-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2058</id>
          <title>An update for mozjs78 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-23"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-23602" id="CVE-2023-23602" title="CVE-2023-23602" type="cve"></reference>
          </references>
          <description>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-23602)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libmozjs-91-0" release="5.oe2203sp1" version="91.6.0">
                         <filename>libmozjs-91-0-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-debuginfo" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debuginfo-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-debugsource" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debugsource-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mozjs91-devel" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-devel-91.6.0-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libmozjs-91-0" release="5.oe2203sp1" version="91.6.0">
                         <filename>libmozjs-91-0-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-debuginfo" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debuginfo-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-debugsource" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-debugsource-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mozjs91-devel" release="5.oe2203sp1" version="91.6.0">
                         <filename>mozjs91-devel-91.6.0-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2062</id>
          <title>An update for php is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-2756" id="CVE-2024-2756" title="CVE-2024-2756" type="cve"></reference>
          </references>
          <description>Due to an incomplete fix to  CVE-2022-31629 https://github.com/advisories/GHSA-c43m-486j-j32p , network and same-site attackers can set a standard insecure cookie in the victim&#39;s browser which is treated as a __Host- or __Secure- cookie by PHP applications. (CVE-2024-2756)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="php" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-enchant" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gd" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-help" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-soap" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-xml" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-help" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="5.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2067</id>
          <title>An update for netty3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-08-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-16869" id="CVE-2019-16869" title="CVE-2019-16869" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-20444" id="CVE-2019-20444" title="CVE-2019-20444" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2019-20445" id="CVE-2019-20445" title="CVE-2019-20445" type="cve"></reference>
          </references>
          <description>Netty before 4.1.42.Final mishandles whitespace before the colon in HTTP headers (such as a &#34;Transfer-Encoding : chunked&#34; line), which leads to HTTP request smuggling.(CVE-2019-16869)HttpObjectDecoder.java in Netty before 4.1.44 allows an HTTP header that lacks a colon, which might be interpreted as a separate header with an incorrect syntax, or might be interpreted as an &#34;invalid fold.&#34;(CVE-2019-20444)HttpObjectDecoder.java in Netty before 4.1.44 allows a Content-Length header to be accompanied by a second Content-Length header, or by a Transfer-Encoding header.(CVE-2019-20445)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="netty3" release="8.oe2203sp1" version="3.10.6">
                         <filename>netty3-3.10.6-8.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2072</id>
          <title>An update for mysql is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0215" id="CVE-2023-0215" title="CVE-2023-0215" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-38545" id="CVE-2023-38545" title="CVE-2023-38545" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21137" id="CVE-2024-21137" title="CVE-2024-21137" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21159" id="CVE-2024-21159" title="CVE-2024-21159" type="cve"></reference>
          </references>
          <description>The public API function BIO_new_NDEF is a helper function used for streamingASN.1 data via a BIO. It is primarily used internally to OpenSSL to support theSMIME, CMS and PKCS7 streaming capabilities, but may also be called directly byend user applications.The function receives a BIO from the caller, prepends a new BIO_f_asn1 filterBIO onto the front of it to form a BIO chain, and then returns the new head ofthe BIO chain to the caller. Under certain conditions, for example if a CMSrecipient public key is invalid, the new filter BIO is freed and the functionreturns a NULL result indicating a failure. However, in this case, the BIO chainis not properly cleaned up and the BIO passed by the caller still retainsinternal pointers to the previously freed filter BIO. If the caller then goes onto call BIO_pop() on the BIO then a use-after-free will occur. This will mostlikely result in a crash.This scenario occurs directly in the internal function B64_write_ASN1() whichmay cause BIO_new_NDEF() to be called and will subsequently call BIO_pop() onthe BIO. This internal function is in turn called by the public API functionsPEM_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 includei2d_ASN1_bio_stream, BIO_new_CMS, BIO_new_PKCS7, i2d_CMS_bio_stream andi2d_PKCS7_bio_stream.The OpenSSL cms and smime command line applications are similarly affected.(CVE-2023-0215)This flaw makes curl overflow a heap based buffer in the SOCKS5 proxyhandshake.When curl is asked to pass along the host name to the SOCKS5 proxy to allowthat to resolve the address instead of it getting done by curl itself, themaximum length that host name can be is 255 bytes.If the host name is detected to be longer, curl switches to local nameresolving and instead passes on the resolved address only. Due to this bug,the local variable that means &#34;let the host resolve the name&#34; could get thewrong 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 theresolved address there.The target buffer being a heap based buffer, and the host name coming from theURL that curl has been told to operate with.(CVE-2023-38545)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-21137)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-21159)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-common" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-common-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-config" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-config-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debuginfo" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debuginfo-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-debugsource" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-debugsource-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-devel" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-devel-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-errmsg" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-errmsg-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-help" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-help-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-libs" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-libs-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-server" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-server-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mysql-test" release="1.oe2203sp1" version="8.0.38">
                         <filename>mysql-test-8.0.38-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2080</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47292" id="CVE-2021-47292" title="CVE-2021-47292" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47504" id="CVE-2021-47504" title="CVE-2021-47504" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-47556" id="CVE-2021-47556" title="CVE-2021-47556" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48634" id="CVE-2022-48634" title="CVE-2022-48634" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48639" id="CVE-2022-48639" title="CVE-2022-48639" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48642" id="CVE-2022-48642" title="CVE-2022-48642" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48643" id="CVE-2022-48643" title="CVE-2022-48643" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48644" id="CVE-2022-48644" title="CVE-2022-48644" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48647" id="CVE-2022-48647" title="CVE-2022-48647" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48648" id="CVE-2022-48648" title="CVE-2022-48648" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48656" id="CVE-2022-48656" title="CVE-2022-48656" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48663" id="CVE-2022-48663" title="CVE-2022-48663" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48671" id="CVE-2022-48671" title="CVE-2022-48671" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48672" id="CVE-2022-48672" title="CVE-2022-48672" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48675" id="CVE-2022-48675" title="CVE-2022-48675" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48686" id="CVE-2022-48686" title="CVE-2022-48686" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48687" id="CVE-2022-48687" title="CVE-2022-48687" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48691" id="CVE-2022-48691" title="CVE-2022-48691" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48873" id="CVE-2022-48873" title="CVE-2022-48873" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48896" id="CVE-2022-48896" title="CVE-2022-48896" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48898" id="CVE-2022-48898" title="CVE-2022-48898" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48899" id="CVE-2022-48899" title="CVE-2022-48899" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48920" id="CVE-2022-48920" title="CVE-2022-48920" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48935" id="CVE-2022-48935" title="CVE-2022-48935" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52893" id="CVE-2023-52893" title="CVE-2023-52893" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52898" id="CVE-2023-52898" title="CVE-2023-52898" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52901" id="CVE-2023-52901" title="CVE-2023-52901" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52903" id="CVE-2023-52903" title="CVE-2023-52903" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22386" id="CVE-2024-22386" title="CVE-2024-22386" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36946" id="CVE-2024-36946" title="CVE-2024-36946" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38613" id="CVE-2024-38613" title="CVE-2024-38613" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39490" id="CVE-2024-39490" title="CVE-2024-39490" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41002" id="CVE-2024-41002" title="CVE-2024-41002" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41068" id="CVE-2024-41068" title="CVE-2024-41068" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42120" id="CVE-2024-42120" title="CVE-2024-42120" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42122" id="CVE-2024-42122" title="CVE-2024-42122" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42265" id="CVE-2024-42265" title="CVE-2024-42265" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42271" id="CVE-2024-42271" title="CVE-2024-42271" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42280" id="CVE-2024-42280" title="CVE-2024-42280" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42281" id="CVE-2024-42281" title="CVE-2024-42281" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42284" id="CVE-2024-42284" title="CVE-2024-42284" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42285" id="CVE-2024-42285" title="CVE-2024-42285" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42297" id="CVE-2024-42297" title="CVE-2024-42297" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42305" id="CVE-2024-42305" title="CVE-2024-42305" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42308" id="CVE-2024-42308" title="CVE-2024-42308" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43819" id="CVE-2024-43819" title="CVE-2024-43819" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43828" id="CVE-2024-43828" title="CVE-2024-43828" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43831" id="CVE-2024-43831" title="CVE-2024-43831" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43853" id="CVE-2024-43853" title="CVE-2024-43853" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43860" id="CVE-2024-43860" title="CVE-2024-43860" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43861" id="CVE-2024-43861" title="CVE-2024-43861" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43866" id="CVE-2024-43866" title="CVE-2024-43866" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43879" id="CVE-2024-43879" title="CVE-2024-43879" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43882" id="CVE-2024-43882" title="CVE-2024-43882" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:io_uring: fix memleak in io_init_wq_offload()I got memory leak report when doing fuzz test:BUG: memory leakunreferenced object 0xffff888107310a80 (size 96):comm &#34;syz-executor.6&#34;, pid 4610, jiffies 4295140240 (age 20.135s)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 ad 4e ad de ff ff ff ff 00 00 00 00 .....N..........backtrace:[&lt;000000001974933b&gt;] kmalloc include/linux/slab.h:591 [inline][&lt;000000001974933b&gt;] kzalloc include/linux/slab.h:721 [inline][&lt;000000001974933b&gt;] io_init_wq_offload fs/io_uring.c:7920 [inline][&lt;000000001974933b&gt;] io_uring_alloc_task_context+0x466/0x640 fs/io_uring.c:7955[&lt;0000000039d0800d&gt;] __io_uring_add_tctx_node+0x256/0x360 fs/io_uring.c:9016[&lt;000000008482e78c&gt;] io_uring_add_tctx_node fs/io_uring.c:9052 [inline][&lt;000000008482e78c&gt;] __do_sys_io_uring_enter fs/io_uring.c:9354 [inline][&lt;000000008482e78c&gt;] __se_sys_io_uring_enter fs/io_uring.c:9301 [inline][&lt;000000008482e78c&gt;] __x64_sys_io_uring_enter+0xabc/0xc20 fs/io_uring.c:9301[&lt;00000000b875f18f&gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline][&lt;00000000b875f18f&gt;] do_syscall_64+0x3b/0x90 arch/x86/entry/common.c:80[&lt;000000006b0a8484&gt;] entry_SYSCALL_64_after_hwframe+0x44/0xaeCPU0                          CPU1io_uring_enter                io_uring_enterio_uring_add_tctx_node        io_uring_add_tctx_node__io_uring_add_tctx_node      __io_uring_add_tctx_nodeio_uring_alloc_task_context   io_uring_alloc_task_contextio_init_wq_offload            io_init_wq_offloadhash = kzalloc                hash = kzallocctx-&gt;hash_map = hash          ctx-&gt;hash_map = hash &lt;- one of the hash is leakedWhen calling io_uring_enter() in parallel, the &#39;hash_map&#39; will be leaked,add uring_lock to protect &#39;hash_map&#39;.(CVE-2021-47292)In the Linux kernel, the following vulnerability has been resolved:io_uring: ensure task_work gets run as part of cancelationsIf we successfully cancel a work item but that work item needs to beprocessed through task_work, then we can be sleeping uninterruptiblyin io_uring_cancel_generic() and never process it. Hence we don&#39;tmake forward progress and we end up with an uninterruptible sleepwarning.While in there, correct a comment that should be IFF, not IIF.(CVE-2021-47504)In the Linux kernel, the following vulnerability has been resolved:ethtool: ioctl: fix potential NULL deref in ethtool_set_coalesce()ethtool_set_coalesce() now uses both the .get_coalesce() and.set_coalesce() callbacks. But the check for their availability isbuggy, so changing the coalesce settings on a device where the driverprovides only _one_ of the callbacks results in a NULL pointerdereference instead of an -EOPNOTSUPP.Fix the condition so that the availability of both callbacks isensured. This also matches the netlink code.Note that reproducing this requires some effort - it only affects thelegacy ioctl path, and needs a specific combination of driver options:- have .get_coalesce() and .coalesce_supported but no .set_coalesce(), or- have .set_coalesce() but no .get_coalesce(). Here eg. ethtool doesn&#39;t  cause the crash as it first attempts to call ethtool_get_coalesce()  and bails out on error.(CVE-2021-47556)In the Linux kernel, the following vulnerability has been resolved:drm/gma500: Fix BUG: sleeping function called from invalid context errorsgma_crtc_page_flip() was holding the event_lock spinlock while callingcrtc_funcs-&gt;mode_set_base() which takes ww_mutex.The only reason to hold event_lock is to clear gma_crtc-&gt;page_flip_eventon mode_set_base() errors.Instead unlock it after setting gma_crtc-&gt;page_flip_event and onerrors re-take the lock and clear gma_crtc-&gt;page_flip_event itit is still set.This fixes the following WARN/stacktrace:[  512.122953] BUG: sleeping function called from invalid context at kernel/locking/mutex.c:870[  512.123004] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1253, name: gnome-shell[  512.123031] preempt_count: 1, expected: 0[  512.123048] RCU nest depth: 0, expected: 0[  512.123066] INFO: lockdep is turned off.[  512.123080] irq event stamp: 0[  512.123094] hardirqs last  enabled at (0): [&lt;0000000000000000&gt;] 0x0[  512.123134] hardirqs last disabled at (0): [&lt;ffffffff8d0ec28c&gt;] copy_process+0x9fc/0x1de0[  512.123176] softirqs last  enabled at (0): [&lt;ffffffff8d0ec28c&gt;] copy_process+0x9fc/0x1de0[  512.123207] softirqs last disabled at (0): [&lt;0000000000000000&gt;] 0x0[  512.123233] Preemption disabled at:[  512.123241] [&lt;0000000000000000&gt;] 0x0[  512.123275] CPU: 3 PID: 1253 Comm: gnome-shell Tainted: G        W         5.19.0+ #1[  512.123304] Hardware name: Packard Bell dot s/SJE01_CT, BIOS V1.10 07/23/2013[  512.123323] Call Trace:[  512.123346]  &lt;TASK&gt;[  512.123370]  dump_stack_lvl+0x5b/0x77[  512.123412]  __might_resched.cold+0xff/0x13a[  512.123458]  ww_mutex_lock+0x1e/0xa0[  512.123495]  psb_gem_pin+0x2c/0x150 [gma500_gfx][  512.123601]  gma_pipe_set_base+0x76/0x240 [gma500_gfx][  512.123708]  gma_crtc_page_flip+0x95/0x130 [gma500_gfx][  512.123808]  drm_mode_page_flip_ioctl+0x57d/0x5d0[  512.123897]  ? drm_mode_cursor2_ioctl+0x10/0x10[  512.123936]  drm_ioctl_kernel+0xa1/0x150[  512.123984]  drm_ioctl+0x21f/0x420[  512.124025]  ? drm_mode_cursor2_ioctl+0x10/0x10[  512.124070]  ? rcu_read_lock_bh_held+0xb/0x60[  512.124104]  ? lock_release+0x1ef/0x2d0[  512.124161]  __x64_sys_ioctl+0x8d/0xd0[  512.124203]  do_syscall_64+0x58/0x80[  512.124239]  ? do_syscall_64+0x67/0x80[  512.124267]  ? trace_hardirqs_on_prepare+0x55/0xe0[  512.124300]  ? do_syscall_64+0x67/0x80[  512.124340]  ? rcu_read_lock_sched_held+0x10/0x80[  512.124377]  entry_SYSCALL_64_after_hwframe+0x63/0xcd[  512.124411] RIP: 0033:0x7fcc4a70740f[  512.124442] Code: 00 48 89 44 24 18 31 c0 48 8d 44 24 60 c7 04 24 10 00 00 00 48 89 44 24 08 48 8d 44 24 20 48 89 44 24 10 b8 10 00 00 00 0f 05 &lt;89&gt; c2 3d 00 f0 ff ff 77 18 48 8b 44 24 18 64 48 2b 04 25 28 00 00[  512.124470] RSP: 002b:00007ffda73f5390 EFLAGS: 00000246 ORIG_RAX: 0000000000000010[  512.124503] RAX: ffffffffffffffda RBX: 000055cc9e474500 RCX: 00007fcc4a70740f[  512.124524] RDX: 00007ffda73f5420 RSI: 00000000c01864b0 RDI: 0000000000000009[  512.124544] RBP: 00007ffda73f5420 R08: 000055cc9c0b0cb0 R09: 0000000000000034[  512.124564] R10: 0000000000000000 R11: 0000000000000246 R12: 00000000c01864b0[  512.124584] R13: 0000000000000009 R14: 000055cc9df484d0 R15: 000055cc9af5d0c0[  512.124647]  &lt;/TASK&gt;(CVE-2022-48634)In the Linux kernel, the following vulnerability has been resolved:net: sched: fix possible refcount leak in tc_new_tfilter()tfilter_put need to be called to put the refount got by tp-&gt;ops-&gt;get toavoid possible refcount leak when chain-&gt;tmplt_ops != NULL andchain-&gt;tmplt_ops != tp-&gt;ops.(CVE-2022-48639)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix percpu memory leak at nf_tables_addchain()It seems to me that percpu memory for chain stats started leaking sincecommit 3bc158f8d0330f0a (&#34;netfilter: nf_tables: map basechain priority tohardware priority&#34;) when nft_chain_offload_priority() returned an error.(CVE-2022-48642)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: fix nft_counters_enabled underflow at nf_tables_addchain()syzbot is reporting underflow of nft_counters_enabled counter atnf_tables_addchain() [1], for commit 43eb8949cfdffa76 (&#34;netfilter:nf_tables: do not leave chain stats enabled on error&#34;) missed thatnf_tables_chain_destroy() after nft_basechain_init() in the error path ofnf_tables_addchain() decrements the counter because nft_basechain_init()makes nft_is_base_chain() return true by setting NFT_CHAIN_BASE flag.Increment the counter immediately after returning fromnft_basechain_init().(CVE-2022-48643)In the Linux kernel, the following vulnerability has been resolved:net/sched: taprio: avoid disabling offload when it was never enabledIn an incredibly strange API design decision, qdisc-&gt;destroy() getscalled even if qdisc-&gt;init() never succeeded, not exclusively sincecommit 87b60cfacf9f (&#34;net_sched: fix error recovery at qdisc creation&#34;),but apparently also earlier (in the case of qdisc_create_dflt()).The taprio qdisc does not fully acknowledge this when it attempts fulloffload, because it starts off with q-&gt;flags = TAPRIO_FLAGS_INVALID intaprio_init(), then it replaces q-&gt;flags with TCA_TAPRIO_ATTR_FLAGSparsed from netlink (in taprio_change(), tail called from taprio_init()).But in taprio_destroy(), we call taprio_disable_offload(), and thisdetermines what to do based on FULL_OFFLOAD_IS_ENABLED(q-&gt;flags).But looking at the implementation of FULL_OFFLOAD_IS_ENABLED()(a bitwise check of bit 1 in q-&gt;flags), it is invalid to call this macroon q-&gt;flags when it contains TAPRIO_FLAGS_INVALID, because that is setto U32_MAX, and therefore FULL_OFFLOAD_IS_ENABLED() will return true onan invalid set of flags.As a result, it is possible to crash the kernel if user space forces anerror between setting q-&gt;flags = TAPRIO_FLAGS_INVALID, and the callingof taprio_enable_offload(). This is because drivers do not expect theoffload to be disabled when it was never enabled.The error that we force here is to attach taprio as a non-root qdisc,but instead as child of an mqprio root qdisc:$ tc qdisc add dev swp0 root handle 1: \&#x9;mqprio num_tc 8 map 0 1 2 3 4 5 6 7 \&#x9;queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 hw 0$ tc qdisc replace dev swp0 parent 1:1 \&#x9;taprio num_tc 8 map 0 1 2 3 4 5 6 7 \&#x9;queues 1@0 1@1 1@2 1@3 1@4 1@5 1@6 1@7 base-time 0 \&#x9;sched-entry S 0x7f 990000 sched-entry S 0x80 100000 \&#x9;flags 0x0 clockid CLOCK_TAIUnable to handle kernel paging request at virtual address fffffffffffffff8[fffffffffffffff8] pgd=0000000000000000, p4d=0000000000000000Internal error: Oops: 96000004 [#1] PREEMPT SMPCall trace: taprio_dump+0x27c/0x310 vsc9959_port_setup_tc+0x1f4/0x460 felix_port_setup_tc+0x24/0x3c dsa_slave_setup_tc+0x54/0x27c taprio_disable_offload.isra.0+0x58/0xe0 taprio_destroy+0x80/0x104 qdisc_create+0x240/0x470 tc_modify_qdisc+0x1fc/0x6b0 rtnetlink_rcv_msg+0x12c/0x390 netlink_rcv_skb+0x5c/0x130 rtnetlink_rcv+0x1c/0x2cFix this by keeping track of the operations we made, and undo theoffload only if we actually did it.I&#39;ve added &#34;bool offloaded&#34; inside a 4 byte hole between &#34;int clockid&#34;and &#34;atomic64_t picos_per_byte&#34;. Now the first cache line looks likebelow:$ pahole -C taprio_sched net/sched/sch_taprio.ostruct taprio_sched {        struct Qdisc * *           qdiscs;               /*     0     8 */        struct Qdisc *             root;                 /*     8     8 */        u32                        flags;                /*    16     4 */        enum tk_offsets            tk_offset;            /*    20     4 */        int                        clockid;              /*    24     4 */        bool                       offloaded;            /*    28     1 */        /* XXX 3 bytes hole, try to pack */        atomic64_t                 picos_per_byte;       /*    32     0 */        /* XXX 8 bytes hole, try to pack */        spinlock_t                 current_entry_lock;   /*    40     0 */        /* XXX 8 bytes hole, try to pack */        struct sched_entry *       current_entry;        /*    48     8 */        struct sched_gate_list *   oper_sched;           /*    56     8 */        /* --- cacheline 1 boundary (64 bytes) --- */(CVE-2022-48644)In the Linux kernel, the following vulnerability has been resolved:sfc: fix TX channel offset when using legacy interruptsIn legacy interrupt mode the tx_channel_offset was hardcoded to 1, butthat&#39;s not correct if efx_sepparate_tx_channels is false. In that case,the offset is 0 because the tx queues are in the single existing channelat index 0, together with the rx queue.Without this fix, as soon as you try to send any traffic, it tries toget the tx queues from an uninitialized channel getting these errors:  WARNING: CPU: 1 PID: 0 at drivers/net/ethernet/sfc/tx.c:540 efx_hard_start_xmit+0x12e/0x170 [sfc]  [...]  RIP: 0010:efx_hard_start_xmit+0x12e/0x170 [sfc]  [...]  Call Trace:   &lt;IRQ&gt;   dev_hard_start_xmit+0xd7/0x230   sch_direct_xmit+0x9f/0x360   __dev_queue_xmit+0x890/0xa40  [...]  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020  [...]  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc]  [...]  Call Trace:   &lt;IRQ&gt;   dev_hard_start_xmit+0xd7/0x230   sch_direct_xmit+0x9f/0x360   __dev_queue_xmit+0x890/0xa40  [...](CVE-2022-48647)In the Linux kernel, the following vulnerability has been resolved:sfc: fix null pointer dereference in efx_hard_start_xmitTrying to get the channel from the tx_queue variable here is wrongbecause we can only be here if tx_queue is NULL, so we shouldn&#39;tdereference it. As the above comment in the code says, this is veryunlikely to happen, but it&#39;s wrong anyway so let&#39;s fix it.I hit this issue because of a different bug that caused tx_queue to beNULL. If that happens, this is the error message that we get here:  BUG: unable to handle kernel NULL pointer dereference at 0000000000000020  [...]  RIP: 0010:efx_hard_start_xmit+0x153/0x170 [sfc](CVE-2022-48648)In the Linux kernel, the following vulnerability has been resolved:dmaengine: ti: k3-udma-private: Fix refcount leak bug in of_xudma_dev_get()We should call of_node_put() for the reference returned byof_parse_phandle() in fail path or when it is not used anymore.Here we only need to move the of_node_put() before the check.(CVE-2022-48656)In the Linux kernel, the following vulnerability has been resolved:gpio: mockup: fix NULL pointer dereference when removing debugfsWe now remove the device&#39;s debugfs entries when unbinding the driver.This now causes a NULL-pointer dereference on module exit because theplatform devices are unregistered *after* the global debugfs directoryhas been recursively removed. Fix it by unregistering the devices first.(CVE-2022-48663)In the Linux kernel, the following vulnerability has been resolved:cgroup: Add missing cpus_read_lock() to cgroup_attach_task_all()syzbot is hitting percpu_rwsem_assert_held(&amp;cpu_hotplug_lock) warning atcpuset_attach() [1], for commit 4f7e7236435ca0ab (&#34;cgroup: Fixthreadgroup_rwsem &lt;-&gt; cpus_read_lock() deadlock&#34;) missed thatcpuset_attach() is also called from cgroup_attach_task_all().Add cpus_read_lock() like what cgroup_procs_write_start() does.(CVE-2022-48671)In the Linux kernel, the following vulnerability has been resolved:of: fdt: fix off-by-one error in unflatten_dt_nodes()Commit 78c44d910d3e (&#34;drivers/of: Fix depth when unflattening devicetree&#34;)forgot to fix up the depth check in the loop body in unflatten_dt_nodes()which makes it possible to overflow the nps[] buffer...Found by Linux Verification Center (linuxtesting.org) with the SVACE staticanalysis tool.(CVE-2022-48672)In the Linux kernel, the following vulnerability has been resolved:IB/core: Fix a nested dead lock as part of ODP flowFix a nested dead lock as part of ODP flow by using mmput_async().From the below call trace [1] can see that calling mmput() once we havethe umem_odp-&gt;umem_mutex locked as required byib_umem_odp_map_dma_and_lock() might trigger in the same task theexit_mmap()-&gt;__mmu_notifier_release()-&gt;mlx5_ib_invalidate_range() whichmay dead lock when trying to lock the same mutex.Moving to use mmput_async() will solve the problem as the aboveexit_mmap() flow will be called in other task and will be executed oncethe lock will be available.[1][64843.077665] task:kworker/u133:2  state:D stack:    0 pid:80906 ppid:2 flags:0x00004000[64843.077672] Workqueue: mlx5_ib_page_fault mlx5_ib_eqe_pf_action [mlx5_ib][64843.077719] Call Trace:[64843.077722]  &lt;TASK&gt;[64843.077724]  __schedule+0x23d/0x590[64843.077729]  schedule+0x4e/0xb0[64843.077735]  schedule_preempt_disabled+0xe/0x10[64843.077740]  __mutex_lock.constprop.0+0x263/0x490[64843.077747]  __mutex_lock_slowpath+0x13/0x20[64843.077752]  mutex_lock+0x34/0x40[64843.077758]  mlx5_ib_invalidate_range+0x48/0x270 [mlx5_ib][64843.077808]  __mmu_notifier_release+0x1a4/0x200[64843.077816]  exit_mmap+0x1bc/0x200[64843.077822]  ? walk_page_range+0x9c/0x120[64843.077828]  ? __cond_resched+0x1a/0x50[64843.077833]  ? mutex_lock+0x13/0x40[64843.077839]  ? uprobe_clear_state+0xac/0x120[64843.077860]  mmput+0x5f/0x140[64843.077867]  ib_umem_odp_map_dma_and_lock+0x21b/0x580 [ib_core][64843.077931]  pagefault_real_mr+0x9a/0x140 [mlx5_ib][64843.077962]  pagefault_mr+0xb4/0x550 [mlx5_ib][64843.077992]  pagefault_single_data_segment.constprop.0+0x2ac/0x560[mlx5_ib][64843.078022]  mlx5_ib_eqe_pf_action+0x528/0x780 [mlx5_ib][64843.078051]  process_one_work+0x22b/0x3d0[64843.078059]  worker_thread+0x53/0x410[64843.078065]  ? process_one_work+0x3d0/0x3d0[64843.078073]  kthread+0x12a/0x150[64843.078079]  ? set_kthread_struct+0x50/0x50[64843.078085]  ret_from_fork+0x22/0x30[64843.078093]  &lt;/TASK&gt;(CVE-2022-48675)In the Linux kernel, the following vulnerability has been resolved:nvme-tcp: fix UAF when detecting digest errorsWe should also bail from the io_work loop when we set rd_enabled to true,so we don&#39;t attempt to read data from the socket when the TCP stream isalready out-of-sync or corrupted.(CVE-2022-48686)In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix out-of-bounds read when setting HMAC data.The SRv6 layer allows defining HMAC data that can later be used to sign IPv6Segment Routing Headers. This configuration is realised via netlink throughfour attributes: SEG6_ATTR_HMACKEYID, SEG6_ATTR_SECRET, SEG6_ATTR_SECRETLEN andSEG6_ATTR_ALGID. Because the SECRETLEN attribute is decoupled from the actuallength of the SECRET attribute, it is possible to provide invalid combinations(e.g., secret = &#34;&#34;, secretlen = 64). This case is not checked in the code andwith an appropriately crafted netlink message, an out-of-bounds read of upto 64 bytes (max secret length) can occur past the skb end pointer and intoskb_shared_info:Breakpoint 1, seg6_genl_sethmac (skb=&lt;optimized out&gt;, info=&lt;optimized out&gt;) at net/ipv6/seg6.c:208208&#x9;&#x9;memcpy(hinfo-&gt;secret, secret, slen);(gdb) bt #0  seg6_genl_sethmac (skb=&lt;optimized out&gt;, info=&lt;optimized out&gt;) at net/ipv6/seg6.c:208 #1  0xffffffff81e012e9 in genl_family_rcv_msg_doit (skb=skb@entry=0xffff88800b1f9f00, nlh=nlh@entry=0xffff88800b1b7600,    extack=extack@entry=0xffffc90000ba7af0, ops=ops@entry=0xffffc90000ba7a80, hdrlen=4, net=0xffffffff84237580 &lt;init_net&gt;, family=&lt;optimized out&gt;,    family=&lt;optimized out&gt;) at net/netlink/genetlink.c:731 #2  0xffffffff81e01435 in genl_family_rcv_msg (extack=0xffffc90000ba7af0, nlh=0xffff88800b1b7600, skb=0xffff88800b1f9f00,    family=0xffffffff82fef6c0 &lt;seg6_genl_family&gt;) at net/netlink/genetlink.c:775 #3  genl_rcv_msg (skb=0xffff88800b1f9f00, nlh=0xffff88800b1b7600, extack=0xffffc90000ba7af0) at net/netlink/genetlink.c:792 #4  0xffffffff81dfffc3 in netlink_rcv_skb (skb=skb@entry=0xffff88800b1f9f00, cb=cb@entry=0xffffffff81e01350 &lt;genl_rcv_msg&gt;)    at net/netlink/af_netlink.c:2501 #5  0xffffffff81e00919 in genl_rcv (skb=0xffff88800b1f9f00) at net/netlink/genetlink.c:803 #6  0xffffffff81dff6ae in netlink_unicast_kernel (ssk=0xffff888010eec800, skb=0xffff88800b1f9f00, sk=0xffff888004aed000)    at net/netlink/af_netlink.c:1319 #7  netlink_unicast (ssk=ssk@entry=0xffff888010eec800, skb=skb@entry=0xffff88800b1f9f00, portid=portid@entry=0, nonblock=&lt;optimized out&gt;)    at net/netlink/af_netlink.c:1345 #8  0xffffffff81dff9a4 in netlink_sendmsg (sock=&lt;optimized out&gt;, msg=0xffffc90000ba7e48, len=&lt;optimized out&gt;) at net/netlink/af_netlink.c:1921...(gdb) p/x ((struct sk_buff *)0xffff88800b1f9f00)-&gt;head + ((struct sk_buff *)0xffff88800b1f9f00)-&gt;end$1 = 0xffff88800b1b76c0(gdb) p/x secret$2 = 0xffff88800b1b76c0(gdb) p slen$3 = 64 &#39;@&#39;The OOB data can then be read back from userspace by dumping HMAC state. Thiscommit fixes this by ensuring SECRETLEN cannot exceed the actual length ofSECRET.(CVE-2022-48687)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: clean up hook list when offload flags check failssplice back the hook list so nft_chain_release_hook() has a chance torelease the hooks.BUG: memory leakunreferenced object 0xffff88810180b100 (size 96):  comm &#34;syz-executor133&#34;, pid 3619, jiffies 4294945714 (age 12.690s)  hex dump (first 32 bytes):    28 64 23 02 81 88 ff ff 28 64 23 02 81 88 ff ff  (d#.....(d#.....    90 a8 aa 83 ff ff ff ff 00 00 b5 0f 81 88 ff ff  ................  backtrace:    [&lt;ffffffff83a8c59b&gt;] kmalloc include/linux/slab.h:600 [inline]    [&lt;ffffffff83a8c59b&gt;] nft_netdev_hook_alloc+0x3b/0xc0 net/netfilter/nf_tables_api.c:1901    [&lt;ffffffff83a9239a&gt;] nft_chain_parse_netdev net/netfilter/nf_tables_api.c:1998 [inline]    [&lt;ffffffff83a9239a&gt;] nft_chain_parse_hook+0x33a/0x530 net/netfilter/nf_tables_api.c:2073    [&lt;ffffffff83a9b14b&gt;] nf_tables_addchain.constprop.0+0x10b/0x950 net/netfilter/nf_tables_api.c:2218    [&lt;ffffffff83a9c41b&gt;] nf_tables_newchain+0xa8b/0xc60 net/netfilter/nf_tables_api.c:2593    [&lt;ffffffff83a3d6a6&gt;] nfnetlink_rcv_batch+0xa46/0xd20 net/netfilter/nfnetlink.c:517    [&lt;ffffffff83a3db79&gt;] nfnetlink_rcv_skb_batch net/netfilter/nfnetlink.c:638 [inline]    [&lt;ffffffff83a3db79&gt;] nfnetlink_rcv+0x1f9/0x220 net/netfilter/nfnetlink.c:656    [&lt;ffffffff83a13b17&gt;] netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]    [&lt;ffffffff83a13b17&gt;] netlink_unicast+0x397/0x4c0 net/netlink/af_netlink.c:1345    [&lt;ffffffff83a13fd6&gt;] netlink_sendmsg+0x396/0x710 net/netlink/af_netlink.c:1921    [&lt;ffffffff83865ab6&gt;] sock_sendmsg_nosec net/socket.c:714 [inline]    [&lt;ffffffff83865ab6&gt;] sock_sendmsg+0x56/0x80 net/socket.c:734    [&lt;ffffffff8386601c&gt;] ____sys_sendmsg+0x36c/0x390 net/socket.c:2482    [&lt;ffffffff8386a918&gt;] ___sys_sendmsg+0xa8/0x110 net/socket.c:2536    [&lt;ffffffff8386aaa8&gt;] __sys_sendmsg+0x88/0x100 net/socket.c:2565    [&lt;ffffffff845e5955&gt;] do_syscall_x64 arch/x86/entry/common.c:50 [inline]    [&lt;ffffffff845e5955&gt;] do_syscall_64+0x35/0xb0 arch/x86/entry/common.c:80    [&lt;ffffffff84800087&gt;] entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2022-48691)In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Don&#39;t remove map on creater_process and device_releaseDo not remove the map from the list on error path infastrpc_init_create_process, instead call fastrpc_map_put, to avoiduse-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-2022-48873)In the Linux kernel, the following vulnerability has been resolved:ixgbe: fix pci device refcount leakAs the comment of pci_get_domain_bus_and_slot() says, itreturns a PCI device with refcount incremented, when finishusing it, the caller must decrement the reference count bycalling pci_dev_put().In ixgbe_get_first_secondary_devfn() and ixgbe_x550em_a_has_mii(),pci_dev_put() is called to avoid leak.(CVE-2022-48896)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 transferThere 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 interruptsources and service the interrupt if its isr status bits shows interruptsare pending. There is potential race condition may happen at current auxisr 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 readtransaction return premature if host aux data read is in the middle ofwaiting for sink to complete transferring data to host while irq happen.This will cause host&#39;s receiving buffer contains unexpected data. Thispatch fixes this problem by checking aux isr and return immediately ataux isr handler if there are no any isr status bits set.Current there is a bug report regrading eDP edid corruption happen duringsystem booting up. After lengthy debugging to found that VIDEO_READYinterrupt was continuously firing during system booting up which causedp_aux_isr() to complete dp_aux_cmd_fifo_tx() prematurely to retrieve datafrom aux hardware buffer which is not yet contains complete data transferfrom sink. This cause edid corruption.Follows are the signature at kernel logs when problem happen,EDID has corrupt headerpanel-simple-dp-aux aux-aea0000.edp: Couldn&#39;t identify panel via EDIDChanges in v2:-- do complete if (ret == IRQ_HANDLED) ay dp-aux_isr()-- add more commit textChanges in v3:-- add Stephen suggested-- dp_aux_isr() return IRQ_XXX back to caller-- dp_ctrl_isr() return IRQ_XXX back to callerChanges in v4:-- split into two patchesChanges in v5:-- delete empty line between tagsChanges in v6:-- remove extra &#34;that&#34; and fixed line more than 75 char at commit textPatchwork: https://patchwork.freedesktop.org/patch/516121/(CVE-2022-48898)In the Linux kernel, the following vulnerability has been resolved:drm/virtio: Fix GEM handle creation UAFUserspace can guess the handle value and try to race GEM object creationwith handle close, resulting in a use-after-free if we dereference theobject after dropping the handle&#39;s reference.  For that reason, droppingthe handle&#39;s reference must be done *after* we are done dereferencingthe object.(CVE-2022-48899)In the Linux kernel, the following vulnerability has been resolved:btrfs: get rid of warning on transaction commit when using flushoncommitWhen using the flushoncommit mount option, during almost every transactioncommit 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 delallocwhen committing a transaction (when using -o flushoncommit), in order toavoid deadlocks with filesystem freeze operations. This change was madeby commit ce8ea7cc6eb313 (&#34;btrfs: don&#39;t call btrfs_start_delalloc_rootsin flushoncommit&#34;). After that change we started producing that warning,and every now and then a user reports this since the warning happens toooften, it spams dmesg/syslog, and a user is unsure if this reflects anyproblem that might compromise the filesystem&#39;s reliability.We can not just lock the sb-&gt;s_umount semaphore before callingwriteback_inodes_sb(), because that would at least deadlock withfilesystem freezing, since at fs/super.c:freeze_super() sync_filesystem()is called while we are holding that semaphore in write mode, and that cantrigger a transaction commit, resulting in a deadlock. It would alsotrigger the same type of deadlock in the unmount path. Possibly, it couldalso introduce some other locking dependencies that lockdep would report.To fix this call try_to_writeback_inodes_sb() instead ofwriteback_inodes_sb(), because that will try to read lock sb-&gt;s_umountand then will only call writeback_inodes_sb() if it was able to lock it.This is fine because the cases where it can&#39;t read lock sb-&gt;s_umountare during a filesystem unmount or during a filesystem freeze - in thosecases sb-&gt;s_umount is write locked and sync_filesystem() is called, whichcalls writeback_inodes_sb(). In other words, in all cases where we can&#39;ttake a read lock on sb-&gt;s_umount, writeback is already being triggeredelsewhere.An alternative would be to call btrfs_start_delalloc_roots() with anumber of pages different from LONG_MAX, for example matching the numberof delalloc bytes we currently have, in ---truncated---(CVE-2022-48920)In the Linux kernel, the following vulnerability has been resolved:netfilter: nf_tables: unregister flowtable hooks on netns exitUnregister flowtable hooks before they are releases vianf_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:142Read of size 4 at addr ffff8880736f7438 by task syz-executor579/3666CPU: 0 PID: 3666 Comm: syz-executor579 Not tainted 5.16.0-rc5-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011Call 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() whichonly unregisters the hooks, then after RCU grace period, it isguaranteed that no packets add new entries to the flowtable (no flowoffload rules and flowtable hooks are reachable from packet path), so itis safe to call nf_flow_table_free() which cleans up the remainingentries from the flowtable (both software and hardware) and it unbindsthe flow_block.(CVE-2022-48935)In the Linux kernel, the following vulnerability has been resolved:gsmi: fix null-deref in gsmi_get_variableWe can get EFI variables without fetching the attribute, so we mustallow for that in gsmi.commit 859748255b43 (&#34;efi: pstore: Omit efivars caching EFI varstoreaccess layer&#34;) added a new get_variable call with attr=NULL, whichtriggers panic in gsmi.(CVE-2023-52893)In the Linux kernel, the following vulnerability has been resolved:xhci: Fix null pointer dereference when host diesMake sure xhci_free_dev() and xhci_kill_endpoint_urbs() do not raceand 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 toloop through all the device&#39;s endpoints, checking if there are anycancelled urbs left to give back.hold the xhci spinlock while freeing the virt device(CVE-2023-52898)In the Linux kernel, the following vulnerability has been resolved:usb: xhci: Check endpoint is valid before dereferencing itWhen the host controller is not responding, all URBs queued to allendpoints need to be killed. This can cause a kernel panic if wedereference an invalid endpoint.Fix this by using xhci_get_virt_ep() helper to find the endpoint andchecking 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-52901)In the Linux kernel, the following vulnerability has been resolved:io_uring: lock overflowing for IOPOLLsyzbot 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:734CPU: 0 PID: 28 Comm: kworker/u4:1 Not tainted 6.2.0-rc3-syzkaller-16369-g358a161a6a9e #0Workqueue: events_unbound io_ring_exit_workCall 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:863There is no real problem for normal IOPOLL as flush is also called withuring_lock taken, but it&#39;s getting more complicated for IOPOLL|SQPOLL,for which __io_cqring_overflow_flush() happens from the CQ waiting path.(CVE-2023-52903)A race condition was found in the Linux kernel&#39;s drm/exynos device driver in exynos_drm_crtc_atomic_disable() function. This can result in a null pointer dereference issue, possibly leading to a kernel panic or denial of service issue.(CVE-2024-22386)In the Linux kernel, the following vulnerability has been resolved:phonet: fix rtm_phonet_notify() skb allocationfill_route() stores three components in the skb:- struct rtmsg- RTA_DST (u8)- RTA_OIF (u32)Therefore, rtm_phonet_notify() should useNLMSG_ALIGN(sizeof(struct rtmsg)) +nla_total_size(1) +nla_total_size(4)(CVE-2024-36946)In the Linux kernel, the following vulnerability has been resolved:m68k: Fix spinlock race in kernel thread creationContext switching does take care to retain the correct lock owner acrossthe switch from &#39;prev&#39; to &#39;next&#39; tasks.  This does rely on interruptsremaining disabled for the entire duration of the switch.This condition is guaranteed for normal process creation and contextswitching between already running processes, because both &#39;prev&#39; and&#39;next&#39; already have interrupts disabled in their saved copies of thestatus register.The situation is different for newly created kernel threads.  The statusregister is set to PS_S in copy_thread(), which does leave the IPL at 0.Upon restoring the &#39;next&#39; thread&#39;s status register in switch_to() akaresume(), interrupts then become enabled prematurely.  resume() thenreturns via ret_from_kernel_thread() and schedule_tail() where run queuelock is released (see finish_task_switch() and finish_lock_switch()).A timer interrupt calling scheduler_tick() before the lock is releasedin finish_task_switch() will find the lock already taken, with thecurrent task as lock owner.  This causes a spinlock recursion warning asreported by Guenter Roeck.As far as I can ascertain, this race has been opened in commit533e6903bea0 (&#34;m68k: split ret_from_fork(), simplify kernel_thread()&#34;)but I haven&#39;t done a detailed study of kernel history so it may wellpredate that commit.Interrupts cannot be disabled in the saved status register copy forkernel threads (init will complain about interrupts disabled whenfinally starting user space).  Disable interrupts temporarily whenswitching the tasks&#39; 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 &#39;spinlock recursion&#39; warning tostill be observed.Tested on ARAnyM and qemu (Quadra 800 emulation).(CVE-2024-38613)In the Linux kernel, the following vulnerability has been resolved:ipv6: sr: fix missing sk_buff release in seg6_input_coreThe seg6_input() function is responsible for adding the SRH into apacket, delegating the operation to the seg6_input_core(). This functionuses the skb_cow_head() to ensure that there is sufficient headroom inthe sk_buff for accommodating the link-layer header.In the event that the skb_cow_header() function fails, theseg6_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 (&#34;ipv6: sr: fix BUG dueto headroom too small after SRH push&#34;) and persists even after commit7a3f5b0de364 (&#34;netfilter: add netfilter hooks to SRv6 data plane&#34;),where the entire seg6_input() code was refactored to deal with netfilterhooks.The proposed patch addresses the identified memory leak by requiring theseg6_input_core() function to release the sk_buff in the event thatskb_cow_head() fails.(CVE-2024-39490)In the Linux kernel, the following vulnerability has been resolved:crypto: hisilicon/sec - Fix memory leak for sec resource releaseThe AIV is one of the SEC resources. When releasing resources,it need to release the AIV resources at the same time.Otherwise, memory leakage occurs.The aiv resource release is added to the sec resource releasefunction.(CVE-2024-41002)In the Linux kernel, the following vulnerability has been resolved:s390/sclp: Fix sclp_init() cleanup on failureIf sclp_init() fails it only partially cleans up: if there are multiplefailing calls to sclp_init() sclp_state_change_event will be added severaltimes 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/0xf8CPU: 0 PID: 1 Comm: swapper/0 Not tainted 6.10.0-rc3Krnl 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/0x30Fix this by removing sclp_state_change_event from sclp_reg_list whensclp_init() fails.(CVE-2024-41068)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check pipe offset before setting vblankpipe_ctx has a size of MAX_PIPES so checking its index before accessingthe array.This fixes an OVERRUN issue reported by Coverity.(CVE-2024-42120)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-42122)In the Linux kernel, the following vulnerability has been resolved:protect the fetch of -&gt;fd[fd] in do_dup2() from mispredictionsboth 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&#39;s wrong for the same reasonswhy it&#39;s wrong in close_fd()/file_close_fd_locked(); the samesolution applies - array_index_nospec(fd, fdt-&gt;max_fds) could differfrom fd only in case of speculative execution on mispredicted path.(CVE-2024-42265)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-42271)In the Linux kernel, the following vulnerability has been resolved:mISDN: Fix a use after free in hfcmulti_tx()Don&#39;t dereference *sp after calling dev_kfree_skb(*sp).(CVE-2024-42280)In the Linux kernel, the following vulnerability has been resolved:bpf: Fix a segment issue when downgrading gso_sizeLinearize the skb when downgrading gso_size because it may trigger aBUG_ON() later when the skb is segmented as described in [1,2].(CVE-2024-42281)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-42284)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-42285)In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to don&#39;t dirty inode for readonly filesystemsyzbot reports f2fs bug as below:kernel BUG at fs/f2fs/inode.c:933!RIP: 0010:f2fs_evict_inode+0x1576/0x1590 fs/f2fs/inode.c:933Call 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/0x6bThe 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 panicWhen we try to repair i_current_depth in readonly filesystem, let&#39;sskip dirty inode to avoid panic in later f2fs_evict_inode().(CVE-2024-42297)In the Linux kernel, the following vulnerability has been resolved:ext4: check dot and dotdot of dx_root before making dir indexedSyzbot reports a issue as follows:============================================BUG: unable to handle page fault for address: ffffed11022e24fePGD 23ffee067 P4D 23ffee067 PUD 0Oops: Oops: 0000 [#1] PREEMPT SMP KASAN PTICPU: 0 PID: 5079 Comm: syz-executor306 Not tainted 6.10.0-rc5-g55027e689933 #0Call Trace: &lt;TASK&gt; make_indexed_dir+0xdaf/0x13c0 fs/ext4/namei.c:2341 ext4_add_entry+0x222a/0x25d0 fs/ext4/namei.c:2451 ext4_rename fs/ext4/namei.c:3936 [inline] ext4_rename2+0x26e5/0x4370 fs/ext4/namei.c:4214[...]============================================The immediate cause of this problem is that there is only one valid dentryfor the block to be split during do_split, so split==0 results in out ofbounds accesses to the map triggering the issue.    do_split      unsigned split      dx_make_map       count = 1      split = count/2 = 0;      continued = hash2 == map[split - 1].hash;       ---&gt; map[4294967295]The maximum length of a filename is 255 and the minimum block size is 1024,so it is always guaranteed that the number of entries is greater than orequal to 2 when do_split() is called.But syzbot&#39;s crafted image has no dot and dotdot in dir, and the dentrydistribution in dirblock is as follows:  bus     dentry1          hole           dentry2           free|xx--|xx-------------|...............|xx-------------|...............|0   12 (8+248)=256  268     256     524 (8+256)=264 788     236     1024So when renaming dentry1 increases its name_len length by 1, neither holenor free is sufficient to hold the new dentry, and make_indexed_dir() iscalled.In make_indexed_dir() it is assumed that the first two entries of thedirblock must be dot and dotdot, so bus and dentry1 are left in dx_rootbecause they are treated as dot and dotdot, and only dentry2 is movedto the new leaf block. That&#39;s why count is equal to 1.Therefore add the ext4_check_dx_root() helper function to add more sanitychecks to dot and dotdot before starting the conversion to avoid the aboveissue.(CVE-2024-42305)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check for NULL pointer[why &amp; how]Need to make sure plane_state is initializedbefore accessing its members.(cherry picked from commit 295d91cbc700651782a60572f83c24861607b648)(CVE-2024-42308)In the Linux kernel, the following vulnerability has been resolved:kvm: s390: Reject memory region operations for ucontrol VMsThis change rejects the KVM_SET_USER_MEMORY_REGION andKVM_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 andwould thus result in a null pointer dereference further in.Memory management needs to be performed in userspace and using theioctls KVM_S390_UCAS_MAP and KVM_S390_UCAS_UNMAP.Also improve s390 specific documentation for KVM_SET_USER_MEMORY_REGIONand KVM_SET_USER_MEMORY_REGION2.[frankja@linux.ibm.com: commit message spelling fix, subject prefix fix](CVE-2024-43819)In the Linux kernel, the following vulnerability has been resolved:ext4: fix infinite loop when replaying fast_commitWhen doing fast_commit replay an infinite loop may occur due to anuninitialized extent_status struct.  ext4_ext_determine_insert_hole() doesnot detect the replay and calls ext4_es_find_extent_range(), which willreturn immediately without initializing the &#39;es&#39; variable.Because &#39;es&#39; contains garbage, an integer overflow may happen causing aninfinite loop in this function, easily reproducible using fstest generic/039.This commit fixes this issue by unconditionally initializing the structurein function ext4_es_find_extent_range().Thanks to Zhang Yi, for figuring out the real problem!(CVE-2024-43828)In the Linux kernel, the following vulnerability has been resolved:media: mediatek: vcodec: Handle invalid decoder vsiHandle an invalid decoder vsi in vpu_dec_init to ensure the decoder vsiis valid for future use.(CVE-2024-43831)In the Linux kernel, the following vulnerability has been resolved:cgroup/cpuset: Prevent UAF in proc_cpuset_show()An UAF can happen when /proc/cpuset is read as reported in [1].This can be reproduced by the following methods:1.add an mdelay(1000) before acquiring the cgroup_lock In the cgroup_path_ns function.2.$cat /proc/&lt;pid&gt;/cpuset   repeatly.3.$mount -t cgroup -o cpuset cpuset /sys/fs/cgroup/cpuset/$umount /sys/fs/cgroup/cpuset/   repeatly.The race that cause this bug can be shown as below:(umount)&#x9;&#x9;|&#x9;(cat /proc/&lt;pid&gt;/cpuset)css_release&#x9;&#x9;|&#x9;proc_cpuset_showcss_release_work_fn&#x9;|&#x9;css = task_get_css(tsk, cpuset_cgrp_id);css_free_rwork_fn&#x9;|&#x9;cgroup_path_ns(css-&gt;cgroup, ...);cgroup_destroy_root&#x9;|&#x9;mutex_lock(&amp;cgroup_mutex);rebind_subsystems&#x9;|cgroup_free_root &#x9;|&#x9;&#x9;&#x9;|&#x9;// cgrp was freed, UAF&#x9;&#x9;&#x9;|&#x9;cgroup_path_ns_locked(cgrp,..);When the cpuset is initialized, the root node top_cpuset.css.cgrpwill point to &amp;cgrp_dfl_root.cgrp. In cgroup v1, the mount operation willallocate cgroup_root, and top_cpuset.css.cgrp will point to the allocated&amp;cgroup_root.cgrp. When the umount operation is executed,top_cpuset.css.cgrp will be rebound to &amp;cgrp_dfl_root.cgrp.The problem is that when rebinding to cgrp_dfl_root, there are caseswhere the cgroup_root allocated by setting up the root for cgroup v1is cached. This could lead to a Use-After-Free (UAF) if it issubsequently freed. The descendant cgroups of cgroup v1 can only befreed after the css is released. However, the css of the root will neverbe released, yet the cgroup_root should be freed when it is unmounted.This means that obtaining a reference to the css of the root doesnot guarantee that css.cgrp-&gt;root will not be freed.Fix this problem by using rcu_read_lock in proc_cpuset_show().As cgroup_root is kfree_rcu after commit d23b5c577715(&#34;cgroup: Make operations on the cgroup root_list RCU safe&#34;),css-&gt;cgroup won&#39;t be freed during the critical section.To call cgroup_path_ns_locked, css_set_lock is needed, so it is safe toreplace task_get_css with task_css.[1] https://syzkaller.appspot.com/bug?extid=9b1ff7be974a403aa4cd(CVE-2024-43853)In the Linux kernel, the following vulnerability has been resolved:remoteproc: imx_rproc: Skip over memory region when node value is NULLIn imx_rproc_addr_init() &#34;nph = of_count_phandle_with_args()&#34; just countsnumber of phandles. But phandles may be empty. So of_parse_phandle() inthe 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-43860)In the Linux kernel, the following vulnerability has been resolved:net: usb: qmi_wwan: fix memory leak for not ip packetsFree the unused skb when not ip packets arrive.(CVE-2024-43861)In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Always drain health in shutdown callbackThere is no point in recovery during device shutdown. if healthwork started need to wait for it to avoid races and NULL pointeraccess.Hence, drain health WQ on shutdown callback.(CVE-2024-43866)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 incfg80211_calculate_bitrate_he(), leading to below warning:kernel: invalid HE MCS: bw:6, ru:6kernel: 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-2024-43879)In the Linux kernel, the following vulnerability has been resolved:exec: Fix ToCToU between perm check and set-uid/gid usageWhen opening a file for exec via do_filp_open(), permission checking isdone against the file&#39;s metadata at that moment, and on success, a filepointer is passed back. Much later in the execve() code path, the filemetadata (specifically mode, uid, and gid) is used to determine if/howto set the uid and gid. However, those values may have changed since thepermissions check, meaning the execution may gain unintended privileges.For example, if a file could change permissions from executable and notset-id:---------x 1 root root 16048 Aug  7 13:16 targetto set-id and non-executable:---S------ 1 root root 16048 Aug  7 13:16 targetit is possible to gain root privileges when execution should have beendisallowed.While this race condition is rare in real-world scenarios, it has beenobserved (and proven exploitable) when package managers are updatingthe setuid bits of installed programs. Such files start with beingworld-executable but then are adjusted to be group-exec with a set-uidbit. For example, &#34;chmod o-x,u+s target&#34; makes &#34;target&#34; executable onlyby uid &#34;root&#34; and gid &#34;cdrom&#34;, while also becoming setuid-root:-rwxr-xr-x 1 root cdrom 16048 Aug  7 13:16 targetbecomes:-rwsr-xr-- 1 root cdrom 16048 Aug  7 13:16 targetBut racing the chmod means users without group &#34;cdrom&#34; membership canget the permission to execute &#34;target&#34; just before the chmod, and whenthe chmod finishes, the exec reaches brpm_fill_uid(), and performs thesetuid to root, violating the expressed authorization of &#34;only cdromgroup members can setuid to root&#34;.Re-check that we still have execute permissions in case the metadatahas 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 afull inode_permission() call (under inode lock). It is understood thatthis is safe against dead-locks, but hardly optimal.(CVE-2024-43882)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.91.0.172.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.91.0.172.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.91.0.172.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2083</id>
          <title>An update for tpm2-tools is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-08-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29038" id="CVE-2024-29038" title="CVE-2024-29038" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29039" id="CVE-2024-29039" title="CVE-2024-29039" type="cve"></reference>
          </references>
          <description>tpm2-tools is the source repository for the Trusted Platform Module (TPM2.0) tools. A malicious attacker can generate arbitrary quote data which is not detected by `tpm2 checkquote`. This issue was patched in version 5.7.(CVE-2024-29038)tpm2 is the source repository for the Trusted Platform Module (TPM2.0) tools. This vulnerability allows attackers to manipulate tpm2_checkquote outputs by altering the TPML_PCR_SELECTION in the PCR input file.  As a result, digest values are incorrectly mapped to PCR slots and banks, providing a misleading picture of the TPM state. This issue has been patched in version 5.7.(CVE-2024-29039)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="tpm2-tools" release="6.oe2203sp1" version="5.0">
                         <filename>tpm2-tools-5.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tpm2-tools-debuginfo" release="6.oe2203sp1" version="5.0">
                         <filename>tpm2-tools-debuginfo-5.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="tpm2-tools-debugsource" release="6.oe2203sp1" version="5.0">
                         <filename>tpm2-tools-debugsource-5.0-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="tpm2-tools-help" release="6.oe2203sp1" version="5.0">
                         <filename>tpm2-tools-help-5.0-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tools" release="6.oe2203sp1" version="5.0">
                         <filename>tpm2-tools-5.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tools-debuginfo" release="6.oe2203sp1" version="5.0">
                         <filename>tpm2-tools-debuginfo-5.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="tpm2-tools-debugsource" release="6.oe2203sp1" version="5.0">
                         <filename>tpm2-tools-debugsource-5.0-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2084</id>
          <title>An update for webkit2gtk3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-08-30"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40779" id="CVE-2024-40779" title="CVE-2024-40779" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40780" id="CVE-2024-40780" title="CVE-2024-40780" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4558" id="CVE-2024-4558" title="CVE-2024-4558" type="cve"></reference>
          </references>
          <description>An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash.(CVE-2024-40779)An out-of-bounds read was addressed with improved bounds checking. This issue is fixed in iOS 16.7.9 and iPadOS 16.7.9, Safari 17.6, iOS 17.6 and iPadOS 17.6, watchOS 10.6, tvOS 17.6, visionOS 1.3, macOS Sonoma 14.6. Processing maliciously crafted web content may lead to an unexpected process crash.(CVE-2024-40780)Use after free in ANGLE in Google Chrome prior to 124.0.6367.155 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page. (Chromium security severity: High)(CVE-2024-4558)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="webkit2gtk3-debugsource" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-debugsource-2.36.3-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-2.36.3-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-jsc-devel" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-jsc-devel-2.36.3-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-devel" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-devel-2.36.3-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-debuginfo" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-debuginfo-2.36.3-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="webkit2gtk3-jsc" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-jsc-2.36.3-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="webkit2gtk3-help" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-help-2.36.3-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-2.36.3-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-debuginfo" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-debuginfo-2.36.3-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-devel" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-devel-2.36.3-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-debugsource" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-debugsource-2.36.3-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-jsc-devel" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-jsc-devel-2.36.3-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="webkit2gtk3-jsc" release="7.oe2203sp1" version="2.36.3">
                         <filename>webkit2gtk3-jsc-2.36.3-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2087</id>
          <title>An update for nginx is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7347" id="CVE-2024-7347" title="CVE-2024-7347" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-7347)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="nginx" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-debuginfo" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-debuginfo-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-debugsource" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-debugsource-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-devel" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-devel-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-image-filter" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-image-filter-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-perl" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-perl-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-http-xslt-filter" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-xslt-filter-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-mail" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-mail-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nginx-mod-stream" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-stream-1.21.5-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-all-modules" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-all-modules-1.21.5-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-filesystem" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-filesystem-1.21.5-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nginx-help" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-help-1.21.5-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-debuginfo" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-debuginfo-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-debugsource" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-debugsource-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-devel" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-devel-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-image-filter" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-image-filter-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-perl" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-perl-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-http-xslt-filter" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-http-xslt-filter-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-mail" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-mail-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nginx-mod-stream" release="7.oe2203sp1" version="1.21.5">
                         <filename>nginx-mod-stream-1.21.5-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2090</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8250" id="CVE-2024-8250" title="CVE-2024-8250" type="cve"></reference>
          </references>
          <description>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(CVE-2024-8250)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="9.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2091</id>
          <title>An update for syslinux is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2011-2501" id="CVE-2011-2501" title="CVE-2011-2501" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2011-2690" id="CVE-2011-2690" title="CVE-2011-2690" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2011-2691" id="CVE-2011-2691" title="CVE-2011-2691" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2011-2692" id="CVE-2011-2692" title="CVE-2011-2692" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2011-3045" id="CVE-2011-3045" title="CVE-2011-3045" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2011-3048" id="CVE-2011-3048" title="CVE-2011-3048" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2012-3425" id="CVE-2012-3425" title="CVE-2012-3425" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-7981" id="CVE-2015-7981" title="CVE-2015-7981" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-8126" id="CVE-2015-8126" title="CVE-2015-8126" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-8472" id="CVE-2015-8472" title="CVE-2015-8472" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2015-8540" id="CVE-2015-8540" title="CVE-2015-8540" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2016-10087" id="CVE-2016-10087" title="CVE-2016-10087" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2017-12652" id="CVE-2017-12652" title="CVE-2017-12652" type="cve"></reference>
          </references>
          <description></description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="syslinux-extlinux-nonlinux" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-extlinux-nonlinux-6.04-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-nonlinux" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-nonlinux-6.04-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="syslinux-tftpboot" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-tftpboot-6.04-16.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-6.04-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debuginfo" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-debuginfo-6.04-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-debugsource" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-debugsource-6.04-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-devel" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-devel-6.04-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-efi64" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-efi64-6.04-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-extlinux" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-extlinux-6.04-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="syslinux-perl" release="16.oe2203sp1" version="6.04">
                         <filename>syslinux-perl-6.04-16.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2095</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2021-3712" id="CVE-2021-3712" title="CVE-2021-3712" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-0778" id="CVE-2022-0778" title="CVE-2022-0778" type="cve"></reference>
          </references>
          <description>ASN.1 strings are represented internally within OpenSSL as an ASN1_STRING structure which contains a buffer holding the string data and a field holding the buffer length. This contrasts with normal C strings which are repesented as a buffer for the string data which is terminated with a NUL (0) byte. Although not a strict requirement, ASN.1 strings that are parsed using OpenSSL&#39;s own &#34;d2i&#34; functions (and other similar parsing functions) as well as any string whose value has been set with the ASN1_STRING_set() function will additionally NUL terminate the byte array in the ASN1_STRING structure. However, it is possible for applications to directly construct valid ASN1_STRING structures which do not NUL terminate the byte array by directly setting the &#34;data&#34; and &#34;length&#34; fields in the ASN1_STRING array. This can also happen by using the ASN1_STRING_set0() function. Numerous OpenSSL functions that print ASN.1 data have been found to assume that the ASN1_STRING byte array will be NUL terminated, even though this is not guaranteed for strings that have been directly constructed. Where an application requests an ASN.1 structure to be printed, and where that ASN.1 structure contains ASN1_STRINGs that have been directly constructed by the application without NUL terminating the &#34;data&#34; field, then a read buffer overrun can occur. The same thing can also occur during name constraints processing of certificates (for example if a certificate has been directly constructed by the application instead of loading it via the OpenSSL parsing functions, and the certificate contains non NUL terminated ASN1_STRING structures). It can also occur in the X509_get1_email(), X509_REQ_get1_email() and X509_get1_ocsp() functions. If a malicious actor can cause an application to directly construct an ASN1_STRING and then process it through one of the affected OpenSSL functions then this issue could be hit. This might result in a crash (causing a Denial of Service attack). It could also result in the disclosure of private memory contents (such as private keys, or sensitive plaintext). Fixed in OpenSSL 1.1.1l (Affected 1.1.1-1.1.1k). Fixed in OpenSSL 1.0.2za (Affected 1.0.2-1.0.2y).(CVE-2021-3712)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-0778)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="20.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="20.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="20.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-20.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="20.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="20.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="20.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="20.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-20.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="20.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="20.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="20.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-20.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2098</id>
          <title>An update for firefox is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0745" id="CVE-2024-0745" title="CVE-2024-0745" type="cve"></reference>
          </references>
          <description>The WebAudio `OscillatorNode` object was susceptible to a stack buffer overflow. This could have led to a potentially exploitable crash. This vulnerability affects Firefox &lt; 122.(CVE-2024-0745)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="firefox" release="7.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debuginfo" release="7.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="firefox-debugsource" release="7.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox" release="7.oe2203sp1" version="102.15.0">
                         <filename>firefox-102.15.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debuginfo" release="7.oe2203sp1" version="102.15.0">
                         <filename>firefox-debuginfo-102.15.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="firefox-debugsource" release="7.oe2203sp1" version="102.15.0">
                         <filename>firefox-debugsource-102.15.0-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2101</id>
          <title>An update for httpd is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38476" id="CVE-2024-38476" title="CVE-2024-38476" type="cve"></reference>
          </references>
          <description>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-38476)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="httpd" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debuginfo" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-debugsource" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-devel" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="httpd-tools" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_ldap" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_md" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_proxy_html" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="mod_session" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="mod_ssl" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-filesystem" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-filesystem-2.4.51-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="httpd-help" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-help-2.4.51-22.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debuginfo" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debuginfo-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-debugsource" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-debugsource-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-devel" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-devel-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="httpd-tools" release="22.oe2203sp1" version="2.4.51">
                         <filename>httpd-tools-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_ldap" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ldap-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_md" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_md-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_proxy_html" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_proxy_html-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="mod_session" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_session-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="mod_ssl" release="22.oe2203sp1" version="2.4.51">
                         <filename>mod_ssl-2.4.51-22.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2102</id>
          <title>An update for expat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45490" id="CVE-2024-45490" title="CVE-2024-45490" type="cve"></reference>
          </references>
          <description>An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.(CVE-2024-45490)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="expat" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-2.4.1-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debuginfo" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debugsource" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-devel" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-devel-2.4.1-12.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="expat-help" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-help-2.4.1-12.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-2.4.1-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debuginfo" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debugsource" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-devel" release="12.oe2203sp1" version="2.4.1">
                         <filename>expat-devel-2.4.1-12.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2104</id>
          <title>An update for linux-firmware is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-31315" id="CVE-2023-31315" title="CVE-2023-31315" type="cve"></reference>
          </references>
          <description>Improper validation in a model specific register (MSR) could allow a malicious program with ring0 access to modify SMM configuration while SMI lock is enabled, potentially leading to arbitrary code execution.(CVE-2023-31315)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="linux-firmware" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-ath" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-ath-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-cypress" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-cypress-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-iwlwifi" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-iwlwifi-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-libertas" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-libertas-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-mediatek" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-mediatek-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-mrvl" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-mrvl-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-netronome" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-netronome-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="linux-firmware-ti-connectivity" release="1.oe2203sp1" version="20240811">
                         <filename>linux-firmware-ti-connectivity-20240811-1.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2106</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48811" id="CVE-2022-48811" title="CVE-2022-48811" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48871" id="CVE-2022-48871" title="CVE-2022-48871" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48875" id="CVE-2022-48875" title="CVE-2022-48875" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48877" id="CVE-2022-48877" title="CVE-2022-48877" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48891" id="CVE-2022-48891" title="CVE-2022-48891" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52889" id="CVE-2023-52889" title="CVE-2023-52889" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52896" id="CVE-2023-52896" title="CVE-2023-52896" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52899" id="CVE-2023-52899" title="CVE-2023-52899" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52906" id="CVE-2023-52906" title="CVE-2023-52906" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40901" id="CVE-2024-40901" title="CVE-2024-40901" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41008" id="CVE-2024-41008" title="CVE-2024-41008" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41016" id="CVE-2024-41016" title="CVE-2024-41016" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41060" id="CVE-2024-41060" title="CVE-2024-41060" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41082" id="CVE-2024-41082" title="CVE-2024-41082" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42153" id="CVE-2024-42153" title="CVE-2024-42153" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42230" id="CVE-2024-42230" title="CVE-2024-42230" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42286" id="CVE-2024-42286" title="CVE-2024-42286" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42288" id="CVE-2024-42288" title="CVE-2024-42288" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42295" id="CVE-2024-42295" title="CVE-2024-42295" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42299" id="CVE-2024-42299" title="CVE-2024-42299" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42312" id="CVE-2024-42312" title="CVE-2024-42312" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43824" id="CVE-2024-43824" title="CVE-2024-43824" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43834" id="CVE-2024-43834" title="CVE-2024-43834" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43854" id="CVE-2024-43854" title="CVE-2024-43854" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43883" id="CVE-2024-43883" title="CVE-2024-43883" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43884" id="CVE-2024-43884" title="CVE-2024-43884" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43889" id="CVE-2024-43889" title="CVE-2024-43889" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43890" id="CVE-2024-43890" title="CVE-2024-43890" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43898" id="CVE-2024-43898" title="CVE-2024-43898" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43905" id="CVE-2024-43905" title="CVE-2024-43905" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43908" id="CVE-2024-43908" title="CVE-2024-43908" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44934" id="CVE-2024-44934" title="CVE-2024-44934" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44938" id="CVE-2024-44938" title="CVE-2024-44938" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44944" id="CVE-2024-44944" title="CVE-2024-44944" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44946" id="CVE-2024-44946" title="CVE-2024-44946" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ibmvnic: don&#39;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 theresources 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 commandseveral times to add/remove a vnic interface:&#x9;[102056] ibmvnic 30000003 env3: Disabling rx_scrq[6] irq&#x9;[102056] ibmvnic 30000003 env3: Disabling rx_scrq[7] irq&#x9;[102056] ibmvnic 30000003 env3: Replenished 8 pools&#x9;Kernel attempted to read user page (10) - exploit attempt? (uid: 0)&#x9;BUG: Kernel NULL pointer dereference on read at 0x00000010&#x9;Faulting instruction address: 0xc000000000a3c840&#x9;Oops: Kernel access of bad area, sig: 11 [#1]&#x9;LE PAGE_SIZE=64K MMU=Radix SMP NR_CPUS=2048 NUMA pSeries&#x9;...&#x9;CPU: 9 PID: 102056 Comm: kworker/9:2 Kdump: loaded Not tainted 5.16.0-rc5-autotest-g6441998e2e37 #1&#x9;Workqueue: events_long __ibmvnic_reset [ibmvnic]&#x9;NIP:  c000000000a3c840 LR: c0080000029b5378 CTR: c000000000a3c820&#x9;REGS: c0000000548e37e0 TRAP: 0300   Not tainted  (5.16.0-rc5-autotest-g6441998e2e37)&#x9;MSR:  8000000000009033 &lt;SF,EE,ME,IR,DR,RI,LE&gt;  CR: 28248484  XER: 00000004&#x9;CFAR: c0080000029bdd24 DAR: 0000000000000010 DSISR: 40000000 IRQMASK: 0&#x9;GPR00: c0080000029b55d0 c0000000548e3a80 c0000000028f0200 0000000000000000&#x9;...&#x9;NIP [c000000000a3c840] napi_enable+0x20/0xc0&#x9;LR [c0080000029b5378] __ibmvnic_open+0xf0/0x430 [ibmvnic]&#x9;Call Trace:&#x9;[c0000000548e3a80] [0000000000000006] 0x6 (unreliable)&#x9;[c0000000548e3ab0] [c0080000029b55d0] __ibmvnic_open+0x348/0x430 [ibmvnic]&#x9;[c0000000548e3b40] [c0080000029bcc28] __ibmvnic_reset+0x500/0xdf0 [ibmvnic]&#x9;[c0000000548e3c60] [c000000000176228] process_one_work+0x288/0x570&#x9;[c0000000548e3d00] [c000000000176588] worker_thread+0x78/0x660&#x9;[c0000000548e3da0] [c0000000001822f0] kthread+0x1c0/0x1d0&#x9;[c0000000548e3e10] [c00000000000cf64] ret_from_kernel_thread+0x5c/0x64&#x9;Instruction dump:&#x9;7d2948f8 792307e0 4e800020 60000000 3c4c01eb 384239e0 f821ffd1 39430010&#x9;38a0fff6 e92d1100 f9210028 39200000 &lt;e9030010&gt; f9010020 60420000 e9210020&#x9;---[ end trace 5f8033b08fd27706 ]---(CVE-2022-48811)In the Linux kernel, the following vulnerability has been resolved:tty: serial: qcom-geni-serial: fix slab-out-of-bounds on RX FIFO bufferDriver&#39;s probe allocates memory for RX FIFO (port-&gt;rx_fifo) based ondefault RX FIFO depth, e.g. 16.  Later during serial startup theqcom_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 &#34;port-&gt;rx_fifo_depth&#34; number of wordsinto &#34;port-&gt;rx_fifo&#34; buffer, thus exceeding the bounds.  This can beobserved in certain configurations with Qualcomm Bluetooth HCI UARTdevice 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/0x64If the RX FIFO depth changes after probe, be sure to resize the buffer.(CVE-2022-48871)In the Linux kernel, the following vulnerability has been resolved:wifi: mac80211: sdata can be NULL during AMPDU startieee80211_tx_ba_session_handle_start() may get NULL for sdata when adeauthentication is ongoing.Here a trace triggering the race with the hostapd testmulti_ap_fronthaul_on_ap:(gdb) list *drv_ampdu_action+0x460x8b16 is in drv_ampdu_action (net/mac80211/driver-ops.c:396).391             int ret = -EOPNOTSUPP;392393             might_sleep();394395             sdata = get_bss_sdata(sdata);396             if (!check_sdata_in_driver(sdata))397                     return -EIO;398399             trace_drv_ampdu_action(local, sdata, params);400wlan0: moving STA 02:00:00:00:03:00 to state 3wlan0: associatedwlan0: deauthenticating from 02:00:00:00:03:00 by local choice (Reason: 3=DEAUTH_LEAVING)wlan3.sta1: Open BA session requested for 02:00:00:00:00:00 tid 0wlan3.sta1: dropped frame to 02:00:00:00:00:00 (unauthorized port)wlan0: moving STA 02:00:00:00:03:00 to state 2wlan0: moving STA 02:00:00:00:03:00 to state 1wlan0: Removed STA 02:00:00:00:03:00wlan0: Destroyed STA 02:00:00:00:03:00BUG: unable to handle page fault for address: fffffffffffffb48PGD 11814067 P4D 11814067 PUD 11816067 PMD 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 2 PID: 133397 Comm: kworker/u16:1 Tainted: G        W          6.1.0-rc8-wt+ #59Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.0-20220807_005459-localhost 04/01/2014Workqueue: phy3 ieee80211_ba_session_work [mac80211]RIP: 0010:drv_ampdu_action+0x46/0x280 [mac80211]Code: 53 48 89 f3 be 89 01 00 00 e8 d6 43 bf ef e8 21 46 81 f0 83 bb a0 1b 00 00 04 75 0e 48 8b 9b 28 0d 00 00 48 81 eb 10 0e 00 00 &lt;8b&gt; 93 58 09 00 00 f6 c2 20 0f 84 3b 01 00 00 8b 05 dd 1c 0f 00 85RSP: 0018:ffffc900025ebd20 EFLAGS: 00010287RAX: 0000000000000000 RBX: fffffffffffff1f0 RCX: ffff888102228240RDX: 0000000080000000 RSI: ffffffff918c5de0 RDI: ffff888102228b40RBP: ffffc900025ebd40 R08: 0000000000000001 R09: 0000000000000001R10: 0000000000000001 R11: 0000000000000000 R12: ffff888118c18ec0R13: 0000000000000000 R14: ffffc900025ebd60 R15: ffff888018b7efb8FS:  0000000000000000(0000) GS:ffff88817a600000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: fffffffffffffb48 CR3: 0000000105228006 CR4: 0000000000170ee0Call Trace: &lt;TASK&gt; ieee80211_tx_ba_session_handle_start+0xd0/0x190 [mac80211] ieee80211_ba_session_work+0xff/0x2e0 [mac80211] process_one_work+0x29f/0x620 worker_thread+0x4d/0x3d0 ? process_one_work+0x620/0x620 kthread+0xfb/0x120 ? kthread_complete_and_exit+0x20/0x20 ret_from_fork+0x22/0x30 &lt;/TASK&gt;(CVE-2022-48875)In the Linux kernel, the following vulnerability has been resolved:f2fs: let&#39;s avoid panic if extent_tree is not createdThis patch avoids the below panic.pc : __lookup_extent_tree+0xd8/0x760lr : f2fs_do_write_data_page+0x104/0x87csp : ffffffc010cbb3c0x29: ffffffc010cbb3e0 x28: 0000000000000000x27: ffffff8803e7f020 x26: ffffff8803e7ed40x25: ffffff8803e7f020 x24: ffffffc010cbb460x23: ffffffc010cbb480 x22: 0000000000000000x21: 0000000000000000 x20: ffffffff22e90900x19: 0000000000000000 x18: ffffffc010c5d080x17: 0000000000000000 x16: 0000000000000020x15: ffffffdb1acdbb88 x14: ffffff888759e2b0x13: 0000000000000000 x12: ffffff802da49000x11: 000000000a001200 x10: ffffff8803e7ed40x9 : ffffff8023195800 x8 : ffffff802da49078x7 : 0000000000000001 x6 : 0000000000000000x5 : 0000000000000006 x4 : ffffffc010cbba28x3 : 0000000000000000 x2 : ffffffc010cbb480x1 : 0000000000000000 x0 : ffffff8803e7ed40Call 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-2022-48877)In the Linux kernel, the following vulnerability has been resolved:regulator: da9211: Use irq handler when readyIf the system does not come from reset (like when it is kexec()), theregulator 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-2022-48891)In the Linux kernel, the following vulnerability has been resolved:apparmor: Fix null pointer deref when receiving skb during sock creationThe panic below is observed when receiving ICMP packets with secmark setwhile an ICMP raw socket is being created. SK_CTX(sk)-&gt;label is updatedin apparmor_socket_post_create(), but the packet is delivered to thesocket 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-2023-52889)In the Linux kernel, the following vulnerability has been resolved:btrfs: fix race between quota rescan and disable leading to NULL pointer derefIf we have one task trying to start the quota rescan worker while anotherone is trying to disable quotas, we can end up hitting a race that resultsin the quota rescan worker doing a NULL pointer dereference. The steps forthis 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 atransaction if it didn&#39;t do any rescan work.(CVE-2023-52896)In the Linux kernel, the following vulnerability has been resolved:Add exception protection processing for vd in axi_chan_handle_err functionSince there is no protection for vd, a kernel panic will betriggered here in exceptional cases.You can refer to the processing of axi_chan_block_xfer_complete functionThe 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-2023-52899)In the Linux kernel, the following vulnerability has been resolved:net/sched: act_mpls: Fix warning during failed attribute validationThe &#39;TCA_MPLS_LABEL&#39; attribute is of &#39;NLA_U32&#39; type, but has avalidation type of &#39;NLA_VALIDATE_FUNCTION&#39;. This is an invalidcombination according to the comment above &#39;struct nla_policy&#39;:&#34;Meaning of `validate&#39; field, use via NLA_POLICY_VALIDATE_FN:   NLA_BINARY           Validation function called for the attribute.   All other            Unused - but note that it&#39;s a union&#34;This can trigger the warning [1] in nla_get_range_unsigned() whenvalidation of the attribute fails. Despite being of &#39;NLA_U32&#39; type, theassociated &#39;min&#39;/&#39;max&#39; fields in the policy are negative as they arealiased by the &#39;validate&#39; field.Fix by changing the attribute type to &#39;NLA_BINARY&#39; which is consistentwith 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:118nla_get_range_unsigned+0x1d8/0x1e0 lib/nlattr.c:117Modules linked in:CPU: 0 PID: 17743 Comm: syz-executor.0 Not tainted 6.1.0-rc8 #3Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOSrel-1.13.0-48-gd9c812dda519-prebuilt.qemu.org 04/01/2014RIP: 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-2023-52906)In the Linux kernel, the following vulnerability has been resolved:scsi: mpt3sas: Avoid test/set_bit() operating in non-allocated memoryThere is a potential out-of-bounds access when using test_bit() on a singleword. The test_bit() and set_bit() functions operate on long values, andwhen testing or setting a single word, they can exceed the wordboundary. KASAN detects this issue and produces a dump:&#x9; BUG: KASAN: slab-out-of-bounds in _scsih_add_device.constprop.0 (./arch/x86/include/asm/bitops.h:60 ./include/asm-generic/bitops/instrumented-atomic.h:29 drivers/scsi/mpt3sas/mpt3sas_scsih.c:7331) mpt3sas&#x9; Write of size 8 at addr ffff8881d26e3c60 by task kworker/u1536:2/2965For full log, please look at [1].Make the allocation at least the size of sizeof(unsigned long) so thatset_bit() and test_bit() have sufficient room for read/write operationswithout overwriting unallocated memory.[1] Link: https://lore.kernel.org/all/ZkNcALr3W3KGYYJG@gmail.com/(CVE-2024-40901)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: change vm-&gt;task_info handlingThis 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 usageof 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-2024-41008)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 &#39;non-indexed&#39;, which saved with additional spacerequested.  It&#39;s better to check if the memory is out of bound beforememcmp, although this possibility mainly comes from crafted poisonousimages.(CVE-2024-41016)In the Linux kernel, the following vulnerability has been resolved:drm/radeon: check bo_va-&gt;bo is non-NULL before using itThe call to radeon_vm_clear_freed might clear bo_va-&gt;bo, sowe have to check it before dereferencing it.(CVE-2024-41060)In the Linux kernel, the following vulnerability has been resolved:nvme-fabrics: use reserved tag for reg read/write commandIn some scenarios, if too many commands are issued by nvme command inthe same time by user tasks, this may exhaust all tags of admin_q. Ifa 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 reservedtags. This maybe safe for nvmf:1. For the disable ctrl path,  we will not issue connect command2. 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-2024-41082)In the Linux kernel, the following vulnerability has been resolved:i2c: pnx: Fix potential deadlock warning from del_timer_sync() call in isrWhen del_timer_sync() is called in an interrupt context it throws a warningbecause of potential deadlock. The timer is used only to exit fromwait_for_completion() after a timeout so replacing the call withwait_for_completion_timeout() allows to remove the problematic timer andits related functions altogether.(CVE-2024-42153)In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries: Fix scv instruction crash with kexeckexec on pseries disables AIL (reloc_on_exc), required for scvinstruction support, before other CPUs have been shut down. This meansthey can execute scv instructions after AIL is disabled, which causes aninterrupt at an unexpected entry location that crashes the kernel.Change the kexec sequence to disable AIL after other CPUs have beenbrought down.As a refresher, the real-mode scv interrupt vector is 0x17000, and thefixed-location head code probably couldn&#39;t easily deal with implementingsuch high addresses so it was just decided not to support that interruptat all.(CVE-2024-42230)In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: validate nvme_local_port correctlyThe driver load failed with error message,qla2xxx [0000:04:00.0]-ffff:0: register_localport failed: ret=ffffffefand with a kernel crash,&#x9;BUG: unable to handle kernel NULL pointer dereference at 0000000000000070&#x9;Workqueue: events_unbound qla_register_fcport_fn [qla2xxx]&#x9;RIP: 0010:nvme_fc_register_remoteport+0x16/0x430 [nvme_fc]&#x9;RSP: 0018:ffffaaa040eb3d98 EFLAGS: 00010282&#x9;RAX: 0000000000000000 RBX: ffff9dfb46b78c00 RCX: 0000000000000000&#x9;RDX: ffff9dfb46b78da8 RSI: ffffaaa040eb3e08 RDI: 0000000000000000&#x9;RBP: ffff9dfb612a0a58 R08: ffffffffaf1d6270 R09: 3a34303a30303030&#x9;R10: 34303a303030305b R11: 2078787832616c71 R12: ffff9dfb46b78dd4&#x9;R13: ffff9dfb46b78c24 R14: ffff9dfb41525300 R15: ffff9dfb46b78da8&#x9;FS:  0000000000000000(0000) GS:ffff9dfc67c00000(0000) knlGS:0000000000000000&#x9;CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033&#x9;CR2: 0000000000000070 CR3: 000000018da10004 CR4: 00000000000206f0&#x9;Call Trace:&#x9;qla_nvme_register_remote+0xeb/0x1f0 [qla2xxx]&#x9;? qla2x00_dfs_create_rport+0x231/0x270 [qla2xxx]&#x9;qla2x00_update_fcport+0x2a1/0x3c0 [qla2xxx]&#x9;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-2024-42286)In the Linux kernel, the following vulnerability has been resolved:scsi: qla2xxx: Fix for possible memory corruptionInit Control Block is dereferenced incorrectly.  Correctly dereference ICB(CVE-2024-42288)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 innilfs_btnode_create_block(), triggering a kernel bug.It is not appropriate to treat this inconsistency as a bug; it can occurif the argument block address (the buffer index of the newly createdblock) is a virtual block number and has been reallocated due tocorruption of the bitmap used to manage its allocation state.So, modify nilfs_btnode_create_block() and its callers to treat it as apossible filesystem error, rather than triggering a kernel bug.(CVE-2024-42295)In the Linux kernel, the following vulnerability has been resolved:fs/ntfs3: Update log-&gt;page_{mask,bits} if log-&gt;page_size changedIf an NTFS file system is mounted to another system with differentPAGE_SIZE from the original system, log-&gt;page_size will change inlog_replay(), but log-&gt;page_{mask,bits} don&#39;t change correspondingly.This will cause a panic because &#34;u32 bytes = log-&gt;page_size - page_off&#34;will get a negative value in the later read_log_page().(CVE-2024-42299)In the Linux kernel, the following vulnerability has been resolved:sysctl: always initialize i_uid/i_gidAlways initialize i_uid/i_gid inside the sysfs core so set_ownership()can safely skip setting them.Commit 5ec27ec735ba (&#34;fs/proc/proc_sysctl.c: fix the default values ofi_uid/i_gid on /proc/sys inodes.&#34;) added defaults for i_uid/i_gid whenset_ownership() was not implemented. It also missed adjustingnet_ctl_set_ownership() to use the same default values in case thecomputation of a better value failed.(CVE-2024-42312)In the Linux kernel, the following vulnerability has been resolved:PCI: endpoint: pci-epf-test: Make use of cached &#39;epc_features&#39; in pci_epf_test_core_init()Instead of getting the epc_features from pci_epc_get_features() API, usethe cached pci_epf_test::epc_features value to avoid the NULL check. Sincethe NULL check is already performed in pci_epf_test_bind(), having one morecheck in pci_epf_test_core_init() is redundant and it is not possible tohit the NULL pointer dereference.Also with commit a01e7214bef9 (&#34;PCI: endpoint: Remove &#34;core_init_notifier&#34;flag&#34;), &#39;epc_features&#39; got dereferenced without the NULL check, leading tothe following false positive Smatch warning:  drivers/pci/endpoint/functions/pci-epf-test.c:784 pci_epf_test_core_init() error: we previously assumed &#39;epc_features&#39; could be null (see line 747)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-43824)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 withpage_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 areference count.When a page pool is destroyed, -&gt;disconnect() is called, which ismem_allocator_disconnect().This function internally acquires mutex_lock().If the driver uses XDP, it registers a memory model withxdp_rxq_info_reg_mem_model().The xdp_rxq_info_reg_mem_model() internally increases a page poolreference 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(), wewill face an invalid wait context warning.Because xdp_unreg_mem_model() calls page_pool_destroy() withrcu_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/0x150other 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 f916f41f172891c800f2fedHardware name: ASUS System Product Name/PRIME Z690-P D4, BIOS 0603 11/01/2021Call 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/0x10lock_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/0x150mem_allocator_disconnect+0x73/0x150? __pfx_mem_allocator_disconnect+0x10/0x10? mark_held_locks+0xa5/0xf0? rcu_is_watching+0x11/0xb0page_pool_release+0x36e/0x6d0page_pool_destroy+0xd7/0x440xdp_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/0x2500xdp_rxq_info_unreg+0x4a/0xd0bnxt_free_mem+0x1356/0x2500bnxt_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/0x10bnxt_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/0x110ethnl_set_features+0x32d/0xa20To fix this problem, it uses rhashtable_lookup_fast() instead ofrhashtable_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 bycall_rcu() of mem_xa_remove().The mem_xa_remove() is called by page_pool_destroy() if a referencecount reaches 0.The xa is already protected by the reference count mechanism well in thecontrol plane.So removing rcu_read_lock() for page_pool_destroy() is safe.(CVE-2024-43834)In the Linux kernel, the following vulnerability has been resolved:block: initialize integrity buffer to zero before writing it to mediaMetadata added by bio_integrity_prep is using plain kmalloc, which leadsto random kernel memory being written media.  For PI metadata this islimited to the app tag that isn&#39;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-43854)In the Linux kernel, the following vulnerability has been resolved:usb: vhci-hcd: Do not drop references before new references are gainedAt a few places the driver carries stale pointersto references that can still be used. Make sure that does not happen.This strictly speaking closes ZDI-CAN-22273, though there may besimilar races in the driver.(CVE-2024-43883)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 NULLpointer dereference causing a crash.Fixed by adding error handling in the function.(CVE-2024-43884)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 atbootup 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-0panic can happen is when ps-&gt;chunk_size is 0.  The way that chunk_size isinitialized in padata_do_multithreaded(), chunk_size can be 0 when themin_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 least1 no matter what the input parameters are.(CVE-2024-43889)In the Linux kernel, the following vulnerability has been resolved:tracing: Fix overflow in get_free_elt()&#34;tracing_map-&gt;next_elt&#34; in get_free_elt() is at risk of overflowing.Once it overflows, new elements can still be inserted into the tracing_mapeven though the maximum number of elements (`max_elts`) has been reached.Continuing to insert elements after the overflow could result in thetracing_map containing &#34;tracing_map-&gt;max_size&#34; elements, leaving no emptyentries.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 preemptiondisabled, leading to a CPU hang problem.Fix this by preventing any further increments to &#34;tracing_map-&gt;next_elt&#34;once it reaches &#34;tracing_map-&gt;max_elt&#34;.(CVE-2024-43890)In the Linux kernel, the following vulnerability has been resolved:ext4: sanity check for NULL pointer after ext4_force_shutdownTest case: 2 threads write short inline data to a file.In ext4_page_mkwrite the resulting inline data is converted.Handling ext4_grp_locked_error with description &#34;block bitmapand bg descriptor inconsistent: X vs Y free clusters&#34; callsext4_force_shutdown. The conversion clearsEXT4_STATE_MAY_INLINE_DATA but fails forext4_destroy_inline_data_nolock and ext4_mark_iloc_dirty dueto ext4_forced_shutdown. The restoration of inline data failsfor the same reason not setting EXT4_STATE_MAY_INLINE_DATA.Without the flag set a regular process path in ext4_da_write_endfollows trying to dereference page folio private pointer that hasnot been set. The fix calls early return with -EIO error shall thepointer to private be NULL.Sample crash report:Unable to handle kernel paging request at virtual address dfff800000000004KASAN: null-ptr-deref in range [0x0000000000000020-0x0000000000000027]Mem abort info:  ESR = 0x0000000096000005  EC = 0x25: DABT (current EL), IL = 32 bits  SET = 0, FnV = 0  EA = 0, S1PTW = 0  FSC = 0x05: level 1 translation faultData abort info:  ISV = 0, ISS = 0x00000005, ISS2 = 0x00000000  CM = 0, WnR = 0, TnD = 0, TagAccess = 0  GCS = 0, Overlay = 0, DirtyBit = 0, Xs = 0[dfff800000000004] address between user and kernel address rangesInternal error: Oops: 0000000096000005 [#1] PREEMPT SMPModules linked in:CPU: 1 PID: 20274 Comm: syz-executor185 Not tainted 6.9.0-rc7-syzkaller-gfda5695d692c #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024pstate: 80400005 (Nzcv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)pc : __block_commit_write+0x64/0x2b0 fs/buffer.c:2167lr : __block_commit_write+0x3c/0x2b0 fs/buffer.c:2160sp : ffff8000a1957600x29: ffff8000a1957610 x28: dfff800000000000 x27: ffff0000e30e34b0x26: 0000000000000000 x25: dfff800000000000 x24: dfff800000000000x23: fffffdffc397c9e0 x22: 0000000000000020 x21: 0000000000000020x20: 0000000000000040 x19: fffffdffc397c9c0 x18: 1fffe000367bd196x17: ffff80008eead000 x16: ffff80008ae89e3c x15: 00000000200000c0x14: 1fffe0001cbe4e04 x13: 0000000000000000 x12: 0000000000000000x11: 0000000000000001 x10: 0000000000ff0100 x9 : 0000000000000000x8 : 0000000000000004 x7 : 0000000000000000 x6 : 0000000000000000x5 : fffffdffc397c9c0 x4 : 0000000000000020 x3 : 0000000000000020x2 : 0000000000000040 x1 : 0000000000000020 x0 : fffffdffc397c9c0Call trace: __block_commit_write+0x64/0x2b0 fs/buffer.c:2167 block_write_end+0xb4/0x104 fs/buffer.c:2253 ext4_da_do_write_end fs/ext4/inode.c:2955 [inline] ext4_da_write_end+0x2c4/0xa40 fs/ext4/inode.c:3028 generic_perform_write+0x394/0x588 mm/filemap.c:3985 ext4_buffered_write_iter+0x2c0/0x4ec fs/ext4/file.c:299 ext4_file_write_iter+0x188/0x1780 call_write_iter include/linux/fs.h:2110 [inline] new_sync_write fs/read_write.c:497 [inline] vfs_write+0x968/0xc3c fs/read_write.c:590 ksys_write+0x15c/0x26c fs/read_write.c:643 __do_sys_write fs/read_write.c:655 [inline] __se_sys_write fs/read_write.c:652 [inline] __arm64_sys_write+0x7c/0x90 fs/read_write.c:652 __invoke_syscall arch/arm64/kernel/syscall.c:34 [inline] invoke_syscall+0x98/0x2b8 arch/arm64/kernel/syscall.c:48 el0_svc_common+0x130/0x23c arch/arm64/kernel/syscall.c:133 do_el0_svc+0x48/0x58 arch/arm64/kernel/syscall.c:152 el0_svc+0x54/0x168 arch/arm64/kernel/entry-common.c:712 el0t_64_sync_handler+0x84/0xfc arch/arm64/kernel/entry-common.c:730 el0t_64_sync+0x190/0x194 arch/arm64/kernel/entry.S:598Code: 97f85911 f94002da 91008356 d343fec8 (38796908)---[ end trace 0000000000000000 ]-------------------Code disassembly (best guess):   0:&#x9;97f85911 &#x9;bl&#x9;0xffffffffffe16444   4:&#x9;f94002da &#x9;ldr&#x9;x26, [x22]   8:&#x9;91008356 &#x9;add&#x9;x22, x26, #0x20   c:&#x9;d343fec8 &#x9;lsr&#x9;x8, x22, #3* 10:&#x9;38796908 &#x9;ldrb&#x9;w8, [x8, x25] &lt;-- trapping instruction(CVE-2024-43898)In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Fix the null pointer dereference for vega10_hwmgrCheck return value and conduct null pointer handling to avoid null pointer dereference.(CVE-2024-43905)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix the null pointer dereference to ras_managerCheck ras_manager before using it(CVE-2024-43908)In the Linux kernel, the following vulnerability has been resolved:net: bridge: mcast: wait for previous gc cycles when removing portsyzbot hit a use-after-free[1] which is caused because the bridge doesn&#39;tmake sure that all previous garbage has been collected when removing aport. 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 runningMake sure all previous gc cycles have finished by using flush_work beforefreeing 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-44934)In the Linux kernel, the following vulnerability has been resolved:jfs: Fix shift-out-of-bounds in dbDiscardAGWhen 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 negativeshift is found.(CVE-2024-44938)In the Linux kernel, the following vulnerability has been resolved:netfilter: ctnetlink: use helper function to calculate expect IDDelete expectation path is missing a call to the nf_expect_get_id()helper function to calculate the expectation ID, otherwise LSB of theexpectation object address is leaked to userspace.(CVE-2024-44944)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 queueWhen a thread is building a MSG_MORE skb, another thread must not touch it.Let&#39;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:1691Read of size 8 at addr ffff0000ced0fc80 by task syz-executor329/6167CPU: 1 PID: 6167 Comm: syz-executor329 Tainted: G    B              6.8.0-rc5-syzkaller-g9abbc24128bc #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/25/2024Call 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:598Allocated 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-44946)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.92.0.173.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.92.0.173.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2113</id>
          <title>An update for jbig2dec is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46361" id="CVE-2023-46361" title="CVE-2023-46361" type="cve"></reference>
          </references>
          <description>Artifex Software jbig2dec v0.20 was discovered to contain a SEGV vulnerability via jbig2_error at /jbig2dec/jbig2.c.(CVE-2023-46361)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="jbig2dec" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-0.19-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jbig2dec-debuginfo" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-debuginfo-0.19-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jbig2dec-debugsource" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-debugsource-0.19-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="jbig2dec-devel" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-devel-0.19-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="jbig2dec-help" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-help-0.19-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jbig2dec" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-0.19-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jbig2dec-debuginfo" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-debuginfo-0.19-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jbig2dec-debugsource" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-debugsource-0.19-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="jbig2dec-devel" release="5.oe2203sp1" version="0.19">
                         <filename>jbig2dec-devel-0.19-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2114</id>
          <title>An update for ruby is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39908" id="CVE-2024-39908" title="CVE-2024-39908" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41123" id="CVE-2024-41123" title="CVE-2024-41123" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43398" id="CVE-2024-43398" title="CVE-2024-43398" type="cve"></reference>
          </references>
          <description> 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-39908)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-41123)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.(CVE-2024-43398)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ruby" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debuginfo" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-debugsource" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ruby-devel" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-bigdecimal" release="139.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-io-console" release="139.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-json" release="139.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-openssl" release="139.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-psych" release="139.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-139.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-help" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-help-3.0.3-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="ruby-irb" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-irb-3.0.3-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-bundler" release="139.oe2203sp1" version="2.2.32">
                         <filename>rubygem-bundler-2.2.32-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-did_you_mean" release="139.oe2203sp1" version="1.5.0">
                         <filename>rubygem-did_you_mean-1.5.0-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-minitest" release="139.oe2203sp1" version="5.14.2">
                         <filename>rubygem-minitest-5.14.2-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rake" release="139.oe2203sp1" version="13.0.3">
                         <filename>rubygem-rake-13.0.3-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rbs" release="139.oe2203sp1" version="1.4.0">
                         <filename>rubygem-rbs-1.4.0-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rdoc" release="139.oe2203sp1" version="6.3.3">
                         <filename>rubygem-rdoc-6.3.3-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rexml" release="139.oe2203sp1" version="3.2.5">
                         <filename>rubygem-rexml-3.2.5-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-rss" release="139.oe2203sp1" version="0.2.9">
                         <filename>rubygem-rss-0.2.9-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-test-unit" release="139.oe2203sp1" version="3.3.7">
                         <filename>rubygem-test-unit-3.3.7-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-typeprof" release="139.oe2203sp1" version="0.15.2">
                         <filename>rubygem-typeprof-0.15.2-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems" release="139.oe2203sp1" version="3.2.32">
                         <filename>rubygems-3.2.32-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygems-devel" release="139.oe2203sp1" version="3.2.32">
                         <filename>rubygems-devel-3.2.32-139.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-3.0.3-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debuginfo" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-debuginfo-3.0.3-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-debugsource" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-debugsource-3.0.3-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ruby-devel" release="139.oe2203sp1" version="3.0.3">
                         <filename>ruby-devel-3.0.3-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-bigdecimal" release="139.oe2203sp1" version="3.0.0">
                         <filename>rubygem-bigdecimal-3.0.0-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-io-console" release="139.oe2203sp1" version="0.5.7">
                         <filename>rubygem-io-console-0.5.7-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-json" release="139.oe2203sp1" version="2.5.1">
                         <filename>rubygem-json-2.5.1-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-openssl" release="139.oe2203sp1" version="2.2.1">
                         <filename>rubygem-openssl-2.2.1-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-psych" release="139.oe2203sp1" version="3.3.2">
                         <filename>rubygem-psych-3.3.2-139.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2115</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43802" id="CVE-2024-43802" title="CVE-2024-43802" type="cve"></reference>
          </references>
          <description>Vim is an improved version of the unix vi text editor. When flushing the typeahead buffer, Vim moves the current position in the typeahead buffer but does not check whether there is enough space left in the buffer to handle the next characters.  So this may lead to the tb_off position within the typebuf variable to point outside of the valid buffer size, which can then later lead to a heap-buffer overflow in e.g. ins_typebuf(). Therefore, when flushing the typeahead buffer, check if there is enough space left before advancing the off position. If not, fall back to flush current typebuf contents. It&#39;s not quite clear yet, what can lead to this situation. It seems to happen when error messages occur (which will cause Vim to flush the typeahead buffer) in comnination with several long mappgins and so it may eventually move the off position out of a valid buffer size. Impact is low since it is not easily reproducible and requires to have several mappings active and run into some error condition. But when this happens, this will cause a crash. The issue has been fixed as of Vim patch v9.1.0697. Users are advised to upgrade. There are no known workarounds for this issue.(CVE-2024-43802)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="27.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="27.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="27.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="27.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="27.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="27.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-27.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="27.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-27.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="27.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="27.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="27.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="27.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="27.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="27.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-27.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2117</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-06"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6923" id="CVE-2024-6923" title="CVE-2024-6923" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-7592" id="CVE-2024-7592" title="CVE-2024-7592" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8088" id="CVE-2024-8088" title="CVE-2024-8088" type="cve"></reference>
          </references>
          <description>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-6923)There is a LOW severity vulnerability affecting CPython, specifically the&#39;http.cookies&#39; standard library module.When parsing cookies that contained backslashes for quoted characters inthe cookie value, the parser would use an algorithm with quadraticcomplexity, resulting in excess CPU resources being used while parsing thevalue.(CVE-2024-7592)There is a HIGH severity vulnerability affecting the CPython &#34;zipfile&#34;module affecting &#34;zipfile.Path&#34;. Note that the more common API &#34;zipfile.ZipFile&#34; class is unaffected.When iterating over names of entries in a zip archive (for example, methodsof &#34;zipfile.Path&#34; like &#34;namelist()&#34;, &#34;iterdir()&#34;, etc)the process can be put into an infinite loop with a maliciously craftedzip archive. This defect applies when reading only metadata or extractingthe contents of the zip archive. Programs that are not handlinguser-controlled zip archives are not affected.(CVE-2024-8088)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-help-3.9.9-31.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2121</id>
          <title>An update for expat is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45491" id="CVE-2024-45491" title="CVE-2024-45491" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45492" id="CVE-2024-45492" title="CVE-2024-45492" type="cve"></reference>
          </references>
          <description>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).(CVE-2024-45491)An issue was discovered in libexpat before 2.6.3. nextScaffoldPart in xmlparse.c can have an integer overflow for m_groupSize on 32-bit platforms (where UINT_MAX equals SIZE_MAX).(CVE-2024-45492)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="expat" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-2.4.1-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debuginfo" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-debugsource" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="expat-devel" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-devel-2.4.1-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="expat-help" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-help-2.4.1-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-2.4.1-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debuginfo" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-debuginfo-2.4.1-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-debugsource" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-debugsource-2.4.1-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="expat-devel" release="13.oe2203sp1" version="2.4.1">
                         <filename>expat-devel-2.4.1-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2123</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48887" id="CVE-2022-48887" title="CVE-2022-48887" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48901" id="CVE-2022-48901" title="CVE-2022-48901" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48902" id="CVE-2022-48902" title="CVE-2022-48902" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45896" id="CVE-2023-45896" title="CVE-2023-45896" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52451" id="CVE-2023-52451" title="CVE-2023-52451" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52488" id="CVE-2023-52488" title="CVE-2023-52488" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52868" id="CVE-2023-52868" title="CVE-2023-52868" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52907" id="CVE-2023-52907" title="CVE-2023-52907" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42259" id="CVE-2024-42259" title="CVE-2024-42259" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42267" id="CVE-2024-42267" title="CVE-2024-42267" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42276" id="CVE-2024-42276" title="CVE-2024-42276" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42311" id="CVE-2024-42311" title="CVE-2024-42311" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43849" id="CVE-2024-43849" title="CVE-2024-43849" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43856" id="CVE-2024-43856" title="CVE-2024-43856" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43899" id="CVE-2024-43899" title="CVE-2024-43899" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43902" id="CVE-2024-43902" title="CVE-2024-43902" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43907" id="CVE-2024-43907" title="CVE-2024-43907" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43914" id="CVE-2024-43914" title="CVE-2024-43914" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44935" id="CVE-2024-44935" title="CVE-2024-44935" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44942" id="CVE-2024-44942" title="CVE-2024-44942" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44947" id="CVE-2024-44947" title="CVE-2024-44947" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44971" id="CVE-2024-44971" title="CVE-2024-44971" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Remove rcu locks from user resourcesUser resource lookups used rcu to avoid two extra atomics. Unfortunatelythe rcu paths were buggy and it was easy to make the driver crash bysubmitting command buffers from two different threads. Because thelookups never show up in performance profiles replace them with aregular spin lock which fixes the races in accesses to those sharedresources.Fixes kernel oops&#39;es in IGT&#39;s vmwgfx execution_buffer stress test andseen crashes with apps using shared resources.(CVE-2022-48887)In the Linux kernel, the following vulnerability has been resolved:btrfs: do not start relocation until in progress drops are doneWe hit a bug with a recovering relocation on mount for one of our filesystems in production.  I reproduced this locally by injecting errorsinto snapshot delete with balance running at the same time.  Thispresented 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 atthe same time by the fs_info-&gt;cleaner_mutex.  However if we had apending balance waiting to get the -&gt;cleaner_mutex, and a snapshotdeletion was running, and then the box crashed, we would come up in astate where we have a half deleted snapshot.Again, in the normal case the snapshot deletion needs to complete beforerelocation can start, but in this case relocation could very well startbefore the snapshot deletion completes, as we simply add the root to thedead roots list and wait for the next time the cleaner runs to clean upthe snapshot.Fix this by setting a bit on the fs_info if we have any DEAD_ROOT&#39;s thathad a pending drop_progress key.  If they do then we know we were in themiddle of the drop operation and set a flag on the fs_info.  Thenbalance can wait until this flag is cleared to start up again.If there are DEAD_ROOT&#39;s that don&#39;t have a drop_progress set then we&#39;resafe to start balance right away as we&#39;ll be properly protected by thecleaner_mutex.(CVE-2022-48901)In the Linux kernel, the following vulnerability has been resolved:btrfs: do not WARN_ON() if we have PageError setWhenever we do any extent buffer operations we callassert_eb_page_uptodate() to complain loudly if we&#39;re operating on annon-uptodate page.  Our overnight tests caught this warning earlier thisweek  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/0x30This was partially fixed by c2e39305299f01 (&#34;btrfs: clear extent bufferuptodate when we fail to write it&#34;), however all that fix did was keepus from finding extent buffers after a failed writeout.  It didn&#39;t keepus from continuing to use a buffer that we already had found.In this case we&#39;re searching the commit root to cache the block group,so we can start committing the transaction and switch the commit rootand then start writing.  After the switch we can look up an extentbuffer that hasn&#39;t been written yet and start processing that blockgroup.  Then we fail to write that block out and clear Uptodate on thepage, and then we start spewing these errors.Normally we&#39;re protected by the tree lock to a certain degree here.  Ifwe read a block we have that block read locked, and we block the writerfrom locking the block before we submit it for the write.  However thisisn&#39;t necessarily fool proof because the read could happen before we dothe submit_bio and after we locked and unlocked the extent buffer.Also in this particular case we have path-&gt;skip_locking set, so thatwon&#39;t save us here.  We&#39;ll simply get a block that was valid when weread it, but became invalid while we were using it.What we really want is to catch the case where we&#39;ve &#34;read&#34; a block butit&#39;s not marked Uptodate.  On read we ClearPageError(), so if we&#39;re!Uptodate and !Error we know we didn&#39;t do the right thing for readingthe page.Fix this by checking !Uptodate &amp;&amp; !Error, this way we will not complainif our buffer gets invalidated while we&#39;re using it, and we&#39;ll maintainthe spirit of the check which is to make sure we have a fully in-cacheblock while we&#39;re messing with it.(CVE-2022-48902)ntfs3 in the Linux kernel through 6.8.0 allows a physically proximate attacker to read kernel memory by mounting a filesystem (e.g., if a Linux distribution is configured to allow unprivileged mounts of removable media) and then leveraging local access to trigger an out-of-bounds read. A length value can be larger than the amount of memory allocated. NOTE: the supplier&#39;s perspective is that there is no vulnerability when an attack requires an attacker-modified filesystem image.(CVE-2023-45896)In the Linux kernel, the following vulnerability has been resolved:powerpc/pseries/memhp: Fix access beyond end of drmem arraydlpar_memory_remove_by_index() may access beyond the bounds of thedrmem lmb array when the LMB lookup fails to match an entry with thegiven 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 thelast valid entry in the array. The debug message at the end of thefunction then dereferences this pointer:        pr_debug(&#34;Failed to hot-remove memory at %llx\n&#34;,                 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 0Log failed lookups with a separate message and dereference thecursor only when it points to a valid entry.(CVE-2023-52451)In the Linux kernel, the following vulnerability has been resolved:serial: sc16is7xx: convert from _raw_ to _noinc_ regmap functions for FIFOThe SC16IS7XX IC supports a burst mode to access the FIFOs where theinitial register address is sent ($00), followed by all the FIFO datawithout having to resend the register address each time. In this mode, theIC doesn&#39;t increment the register address for each R/W byte.The regmap_raw_read() and regmap_raw_write() are functions which canperform IO over multiple registers. They are currently used to read/writefrom/to the FIFO, and although they operate correctly in this burst mode onthe SPI bus, they would corrupt the regmap cache if it was not disabledmanually. The reason is that when the R/W size is more than 1 byte, thesefunctions assume that the register address is incremented and handle thecache accordingly.Convert FIFO R/W functions to use the regmap _noinc_ versions in order toremove the manual cache control which was a workaround when using the_raw_ versions. FIFO registers are properly declared as volatile socache will not be used/updated for FIFO accesses.(CVE-2023-52488)In the Linux kernel, the following vulnerability has been resolved:thermal: core: prevent potential string overflowThe dev-&gt;id value comes from ida_alloc() so it&#39;s a number between zeroand INT_MAX.  If it&#39;s too high then these sprintf()s will overflow.(CVE-2023-52868)In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Wait for out_urb&#39;s completion in pn533_usb_send_frame()Fix a use-after-free that occurs in hcd when in_urb sent frompn533_usb_send_frame() is completed earlier than out_urb. Its callbackfrees the skb data in pn533_send_async_complete() that is used as atransfer buffer of out_urb. Wait before sending in_urb until thecallback 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_timerCall 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-2023-52907)In the Linux kernel, the following vulnerability has been resolved:drm/i915/gem: Fix Virtual Memory mapping boundaries calculationCalculating the size of the mapped area as the lesser valuebetween the requested size and the actual size does not considerthe partial mapping offset. This can cause page fault access.Fix the calculation of the starting and ending addresses, thetotal size is now deduced from the difference between the end andstart addresses.Additionally, the calculations have been rewritten in a clearerand more understandable form.[Joonas: Add Requires: tag]Requires: 60a2066c5005 (&#34;drm/i915/gem: Adjust vma offset for framebuffer mmap offset&#34;)(cherry picked from commit 97b6784753da06d9d40232328efc5c5367e53417)(CVE-2024-42259)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 correctlykill the process and we don&#39;t BUG() the kernel.(CVE-2024-42267)In the Linux kernel, the following vulnerability has been resolved:nvme-pci: add missing condition check for existence of mapped datanvme_map_data() is called when request has physical segments, hencethe nvme_unmap_data() should have same condition to avoid dereference.(CVE-2024-42276)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/0x6bBUG: 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/0x82Uninit 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/0x6bIt missed to initialize .tz_secondswest, .cached_start and .cached_blocksfields in struct hfs_inode_info after hfs_alloc_inode(), fix it.(CVE-2024-42311)In the Linux kernel, the following vulnerability has been resolved:soc: qcom: pdr: protect locator_addr with the main mutexIf the service locator server is restarted fast enough, the PDR canrewrite locator_addr fields concurrently. Protect them by placingmodification of those fields under the main pdr-&gt;lock.(CVE-2024-43849)In the Linux kernel, the following vulnerability has been resolved:dma: fix call order in dmam_free_coherentdmam_free_coherent() frees a DMA allocation, which makes thefreed vaddr available for reuse, then calls devres_destroy()to remove and free the data structure used to track the DMAallocation. Between the two calls, it is possible for aconcurrent task to make an allocation with the same vaddrand add it to the devres list.If this happens, there will be two entries in the devres listwith the same vaddr and devres_destroy() can free the wrongentry, triggering the WARN_ON() in dmam_match.Fix by destroying the devres entry before freeing the DMAallocation.  kokonut //net/encryption    http://sponge2/b9145fe6-0f72-4325-ac2f-a84d81075b03(CVE-2024-43856)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Fix null pointer deref in dcn20_resource.cFixes a hang thats triggered when MPV is run on a DCN401 dGPU:mpv --hwdec=vaapi --vo=gpu --hwdec-codecs=alland 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-43899)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add null checker before passing variablesChecks null pointer before passing variables to functions.This fixes 3 NULL_RETURNS issues reported by Coverity.(CVE-2024-43902)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu/pm: Fix the null pointer dereference in apply_state_adjust_rulesCheck the pointer value to fix potential null pointerdereference(CVE-2024-43907)In the Linux kernel, the following vulnerability has been resolved:md/raid5: avoid BUG_ON() while continue reshape after reassemblingCurrently, mdadm support --revert-reshape to abort the reshape whilereassembling, 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 PTIirq event stamp: 158985CPU: 6 PID: 891 Comm: md0_reshape Not tainted 6.9.0-03335-g7592a0b0049a #94RIP: 0010:reshape_request+0x3f1/0xe60Call 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 thechecking of &#39;writepos&#39; that is caculated by old reshape position willfail.Fix this panic the easy way first, by converting the BUG_ON() toWARN_ON(), and stop the reshape if checkings fail.Noted that mdadm must fix --revert-shape as well, and probably md/raidshould enhance metadata validation as well, however this meansreassemble will fail and there must be user tools to fix the wrongmetadata.(CVE-2024-43914)In the Linux kernel, the following vulnerability has been resolved:sctp: Fix null-ptr-deref in reuseport_add_sock().syzbot reported a null-ptr-deref while accessing sk2-&gt;sk_reuseport_cb inreuseport_add_sock(). [0]The repro first creates a listener with SO_REUSEPORT.  Then, it createsanother listener on the same port and concurrently closes the firstlistener.The second listen() calls reuseport_add_sock() with the first listener assk2, where sk2-&gt;sk_reuseport_cb is not expected to be cleared concurrently,but the close() does clear it by reuseport_detach_sock().The problem is SCTP does not properly synchronise reuseport_alloc(),reuseport_add_sock(), and reuseport_detach_sock().The caller of reuseport_alloc() and reuseport_{add,detach}_sock() mustprovide synchronisation for sockets that are classified into the samereuseport group.Otherwise, such sockets form multiple identical reuseport groups, andall groups except one would be silently dead.  1. Two sockets call listen() concurrently  2. No socket in the same group found in sctp_ep_hashtable[]  3. Two sockets call reuseport_alloc() and form two reuseport groups  4. Only one group hit first in __sctp_rcv_lookup_endpoint() receives      incoming packetsAlso, the reported null-ptr-deref could occur.TCP/UDP guarantees that would not happen by holding the hash bucket lock.Let&#39;s apply the locking strategy to __sctp_hash_endpoint() and__sctp_unhash_endpoint().[0]:Oops: general protection fault, probably for non-canonical address 0xdffffc0000000002: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000010-0x0000000000000017]CPU: 1 UID: 0 PID: 10230 Comm: syz-executor119 Not tainted 6.10.0-syzkaller-12585-g301927d2d2eb #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024RIP: 0010:reuseport_add_sock+0x27e/0x5e0 net/core/sock_reuseport.c:350Code: 00 0f b7 5d 00 bf 01 00 00 00 89 de e8 1b a4 ff f7 83 fb 01 0f 85 a3 01 00 00 e8 6d a0 ff f7 49 8d 7e 12 48 89 f8 48 c1 e8 03 &lt;42&gt; 0f b6 04 28 84 c0 0f 85 4b 02 00 00 41 0f b7 5e 12 49 8d 7e 14RSP: 0018:ffffc9000b947c98 EFLAGS: 00010202RAX: 0000000000000002 RBX: ffff8880252ddf98 RCX: ffff888079478000RDX: 0000000000000000 RSI: 0000000000000001 RDI: 0000000000000012RBP: 0000000000000001 R08: ffffffff8993e18d R09: 1ffffffff1fef385R10: dffffc0000000000 R11: fffffbfff1fef386 R12: ffff8880252ddac0R13: dffffc0000000000 R14: 0000000000000000 R15: 0000000000000000FS:  00007f24e45b96c0(0000) GS:ffff8880b9300000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007ffcced5f7b8 CR3: 00000000241be000 CR4: 00000000003506f0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400Call Trace: &lt;TASK&gt; __sctp_hash_endpoint net/sctp/input.c:762 [inline] sctp_hash_endpoint+0x52a/0x600 net/sctp/input.c:790 sctp_listen_start net/sctp/socket.c:8570 [inline] sctp_inet_listen+0x767/0xa20 net/sctp/socket.c:8625 __sys_listen_socket net/socket.c:1883 [inline] __sys_listen+0x1b7/0x230 net/socket.c:1894 __do_sys_listen net/socket.c:1902 [inline] __se_sys_listen net/socket.c:1900 [inline] __x64_sys_listen+0x5a/0x70 net/socket.c:1900 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/0x7fRIP: 0033:0x7f24e46039b9Code: 28 00 00 00 75 05 48 83 c4 28 c3 e8 91 1a 00 00 90 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 &lt;48&gt; 3d 01 f0 ff ff 73 01 c3 48 c7 c1 b0 ff ff ff f7 d8 64 89 01 48RSP: 002b:00007f24e45b9228 EFLAGS: 00000246 ORIG_RAX: 0000000000000032RAX: ffffffffffffffda RBX: 00007f24e468e428 RCX: 00007f24e46039b9RDX: 00007f24e46039b9 RSI: 0000000000000003 RDI: 0000000000000004RBP: 00007f24e468e420 R08: 00007f24e45b96c0 R09: 00007f24e45b96c0R10: 00007f24e45b96c0 R11: 0000000000000246 R12: 00007f24e468e42cR13:---truncated---(CVE-2024-44935)In the Linux kernel, the following vulnerability has been resolved:f2fs: fix to do sanity check on F2FS_INLINE_DATA flag in inode during GCsyzbot 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 #0RIP: 0010:f2fs_write_inline_data+0x781/0x790 fs/f2fs/inline.c:258Call 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:244The root cause is: inline_data inode can be fuzzed, so that there maybe valid blkaddr in its direct node, once f2fs triggers background GCto migrate the block, it will hit f2fs_bug_on() during dirty pagewriteback.Let&#39;s add sanity check on F2FS_INLINE_DATA flag in inode during GC,so that, it can forbid migrating inline_data inode&#39;s data block forfixing.(CVE-2024-44942)In the Linux kernel, the following vulnerability has been resolved:fuse: Initialize beyond-EOF page contents before setting uptodatefuse_notify_store(), unlike fuse_do_readpage(), does not enable pagezeroing (because it can be used to change partial page contents).So fuse_notify_store() must be more careful to fully initialize pagecontents (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, whichmakes these uninitialized page contents visible to userspace via mmap().This is an information leak, but only affects systems which do notenable init-on-alloc (via CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y or thecorresponding kernel command line parameter).(CVE-2024-44947)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 thenphy_device_remove() in a loop to remove existing PHY devices.of_phy_find_device() eventually calls bus_find_device(), which callsget_device() on the returned struct device * to increment the refcount.The current implementation does not decrement the refcount, which causesmemory leak.This commit adds the missing phy_device_free() call to decrement therefcount via put_device() to balance the refcount.(CVE-2024-44971)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.93.0.174.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.93.0.174.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.93.0.174.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2132</id>
          <title>An update for clamav is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20505" id="CVE-2024-20505" title="CVE-2024-20505" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-20506" id="CVE-2024-20506" title="CVE-2024-20506" type="cve"></reference>
          </references>
          <description>A vulnerability in the PDF parsing module of Clam AntiVirus (ClamAV) versions 1.4.0, 1.3.2 and prior versions, all 1.2.x versions, 1.0.6 and prior versions, all 0.105.x versions, all 0.104.x versions, and 0.103.11 and all prior versions could allow an unauthenticated, remote attacker to cause a denial of service (DoS) condition on an affected device.The vulnerability is due to an out of bounds read. An attacker could exploit this vulnerability by submitting a crafted PDF file to be scanned by ClamAV on an affected device. An exploit could allow the attacker to terminate the scanning process.(CVE-2024-20505)A vulnerability in the ClamD service module of Clam AntiVirus (ClamAV) versions 1.4.0, 1.3.2 and prior versions, all 1.2.x versions, 1.0.6 and prior versions, all 0.105.x versions, all 0.104.x versions, and 0.103.11 and all prior versions could allow an authenticated, local attacker to corrupt critical system files.The vulnerability is due to allowing the ClamD process to write to its log file while privileged without checking if the logfile has been replaced with a symbolic link. An attacker could exploit this vulnerability if they replace the ClamD log file with a symlink to a critical system file and then find a way to restart the ClamD process. An exploit could allow the attacker to corrupt a critical system file by appending ClamD log messages after restart.(CVE-2024-20506)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="clamav" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-0.103.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-debuginfo" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-debuginfo-0.103.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-debugsource" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-debugsource-0.103.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-devel" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-devel-0.103.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-milter" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-milter-0.103.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamav-update" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-update-0.103.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="clamd" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamd-0.103.12-1.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-data" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-data-0.103.12-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-filesystem" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-filesystem-0.103.12-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="clamav-help" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-help-0.103.12-1.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-0.103.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-debuginfo" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-debuginfo-0.103.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-debugsource" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-debugsource-0.103.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-devel" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-devel-0.103.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-milter" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-milter-0.103.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamav-update" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamav-update-0.103.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="clamd" release="1.oe2203sp1" version="0.103.12">
                         <filename>clamd-0.103.12-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2133</id>
          <title>An update for osc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22034" id="CVE-2024-22034" title="CVE-2024-22034" type="cve"></reference>
          </references>
          <description>(CVE-2024-22034)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="osc" release="2.oe2203sp1" version="0.177.0">
                         <filename>osc-0.177.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="osc-help" release="2.oe2203sp1" version="0.177.0">
                         <filename>osc-help-0.177.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2136</id>
          <title>An update for runc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45310" id="CVE-2024-45310" title="CVE-2024-45310" type="cve"></reference>
          </references>
          <description>runc is a CLI tool for spawning and running containers according to the OCI specification. runc 1.1.13 and earlier, as well as 1.2.0-rc2 and earlier, can be tricked into creating empty files or directories in arbitrary locations in the host filesystem by sharing a volume between two containers and exploiting a race with `os.MkdirAll`. While this could be used to create empty files, existing files would not be truncated. An attacker must have the ability to start containers using some kind of custom volume configuration. Containers using user namespaces are still affected, but the scope of places an attacker can create inodes can be significantly reduced. Sufficiently strict LSM policies (SELinux/Apparmor) can also in principle block this attack -- we suspect the industry standard SELinux policy may restrict this attack&#39;s scope but the exact scope of protection hasn&#39;t been analysed. This is exploitable using runc directly as well as through Docker and Kubernetes. The issue is fixed in runc v1.1.14 and v1.2.0-rc3.Some workarounds are available. Using user namespaces restricts this attack fairly significantly such that the attacker can only create inodes in directories that the remapped root user/group has write access to. Unless the root user is remapped to an actualuser on the host (such as with rootless containers that don&#39;t use `/etc/sub[ug]id`), this in practice means that an attacker would only be able to create inodes in world-writable directories. A strict enough SELinux or AppArmor policy could in principle also restrict the scope if a specific label is applied to the runc runtime, though neither the extent to which the standard existing policies block this attack nor what exact policies are needed to sufficiently restrict this attack have been thoroughly tested.(CVE-2024-45310)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="docker-runc" release="30.oe2203sp1" version="1.1.3">
                         <filename>docker-runc-1.1.3-30.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="docker-runc" release="30.oe2203sp1" version="1.1.3">
                         <filename>docker-runc-1.1.3-30.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2138</id>
          <title>An update for xmlrpc-c is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45490" id="CVE-2024-45490" title="CVE-2024-45490" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45491" id="CVE-2024-45491" title="CVE-2024-45491" type="cve"></reference>
          </references>
          <description>An issue was discovered in libexpat before 2.6.3. xmlparse.c does not reject a negative length for XML_ParseBuffer.(CVE-2024-45490)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).(CVE-2024-45491)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xmlrpc-c" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-1.51.08-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xmlrpc-c-debuginfo" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-debuginfo-1.51.08-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xmlrpc-c-debugsource" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-debugsource-1.51.08-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xmlrpc-c-devel" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-devel-1.51.08-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xmlrpc-c-help" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-help-1.51.08-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmlrpc-c" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-1.51.08-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmlrpc-c-debuginfo" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-debuginfo-1.51.08-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmlrpc-c-debugsource" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-debugsource-1.51.08-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xmlrpc-c-devel" release="3.oe2203sp1" version="1.51.08">
                         <filename>xmlrpc-c-devel-1.51.08-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2140</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-42667" id="CVE-2023-42667" title="CVE-2023-42667" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-49141" id="CVE-2023-49141" title="CVE-2023-49141" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24853" id="CVE-2024-24853" title="CVE-2024-24853" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24980" id="CVE-2024-24980" title="CVE-2024-24980" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25939" id="CVE-2024-25939" title="CVE-2024-25939" type="cve"></reference>
          </references>
          <description>Improper isolation in the Intel(R) Core(TM) Ultra Processor stream cache mechanism may allow an authenticated user to potentially enable escalation of privilege via local access.(CVE-2023-42667)Improper isolation in some Intel(R) Processors stream cache mechanism may allow an authenticated user to potentially enable escalation of privilege via local access.(CVE-2023-49141)Incorrect behavior order in transition between executive monitor and SMI transfer monitor (STM) in some Intel(R) Processor may allow a privileged user to potentially enable escalation of privilege via local access.(CVE-2024-24853)Protection mechanism failure in some 3rd, 4th, and 5th Generation Intel(R) Xeon(R) Processors may allow a privileged user to potentially enable escalation of privilege via local access.(CVE-2024-24980)Mirrored regions with different values in 3rd Generation Intel(R) Xeon(R) Scalable Processors may allow a privileged user to potentially enable denial of service via local access.(CVE-2024-25939)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="1.oe2203sp1" version="20240813">
                         <filename>microcode_ctl-20240813-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2141</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-0450" id="CVE-2024-0450" title="CVE-2024-0450" type="cve"></reference>
          </references>
          <description>An issue was found in the CPython `zipfile` module affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.The zipfile module is vulnerable to “quoted-overlap” zip-bombs which exploit the zip format to create a zip-bomb with a high compression ratio. The fixed versions of CPython makes the zipfile module reject zip archives which overlap entries in the archive.(CVE-2024-0450)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-31.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-help-3.9.9-31.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="31.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-31.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2142</id>
          <title>An update for wpa_supplicant is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-14"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5290" id="CVE-2024-5290" title="CVE-2024-5290" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-5290)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-2.6-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant-debuginfo" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-debuginfo-2.6-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant-debugsource" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-debugsource-2.6-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant-gui" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-gui-2.6-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wpa_supplicant-help" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-help-2.6-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-2.6-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant-debuginfo" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-debuginfo-2.6-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant-debugsource" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-debugsource-2.6-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant-gui" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-gui-2.6-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wpa_supplicant-help" release="32.oe2203sp1" version="2.6">
                         <filename>wpa_supplicant-help-2.6-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2147</id>
          <title>An update for fence-agents is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52323" id="CVE-2023-52323" title="CVE-2023-52323" type="cve"></reference>
          </references>
          <description>PyCryptodome and pycryptodomex before 3.19.1 allow side-channel leakage for OAEP decryption, exploitable for a Manger attack.(CVE-2023-52323)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="fence-agents-all" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-all-4.2.1-33.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fence-agents-debuginfo" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-debuginfo-4.2.1-33.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fence-agents-debugsource" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-debugsource-4.2.1-33.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fence-agents-kdump" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-kdump-4.2.1-33.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="fence-agents-redfish" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-redfish-4.2.1-33.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-amt-ws" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-amt-ws-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-apc" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-apc-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-apc-snmp" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-apc-snmp-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-aws" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-aws-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-bladecenter" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-bladecenter-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-brocade" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-brocade-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-cisco-mds" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-cisco-mds-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-cisco-ucs" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-cisco-ucs-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-common" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-common-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-compute" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-compute-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-drac5" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-drac5-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-eaton-snmp" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-eaton-snmp-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-emerson" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-emerson-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-eps" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-eps-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-gce" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-gce-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-heuristics-ping" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-heuristics-ping-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-hpblade" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-hpblade-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ibmblade" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-ibmblade-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ifmib" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-ifmib-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ilo-moonshot" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-ilo-moonshot-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ilo-mp" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-ilo-mp-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ilo-ssh" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-ilo-ssh-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ilo2" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-ilo2-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-intelmodular" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-intelmodular-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ipdu" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-ipdu-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-ipmilan" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-ipmilan-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-mpath" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-mpath-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-rhevm" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-rhevm-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-rsa" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-rsa-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-rsb" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-rsb-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-sbd" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-sbd-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-scsi" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-scsi-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-virsh" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-virsh-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-vmware-rest" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-vmware-rest-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-vmware-soap" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-vmware-soap-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="fence-agents-wti" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-wti-4.2.1-33.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-aliyun" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-aliyun-4.2.1-33.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-all" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-all-4.2.1-33.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-debuginfo" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-debuginfo-4.2.1-33.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-debugsource" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-debugsource-4.2.1-33.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-kdump" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-kdump-4.2.1-33.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="fence-agents-redfish" release="33.oe2203sp1" version="4.2.1">
                         <filename>fence-agents-redfish-4.2.1-33.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2153</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52742" id="CVE-2023-52742" title="CVE-2023-52742" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52915" id="CVE-2023-52915" title="CVE-2023-52915" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52916" id="CVE-2023-52916" title="CVE-2023-52916" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36934" id="CVE-2024-36934" title="CVE-2024-36934" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36941" id="CVE-2024-36941" title="CVE-2024-36941" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43829" id="CVE-2024-43829" title="CVE-2024-43829" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44960" id="CVE-2024-44960" title="CVE-2024-44960" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44986" id="CVE-2024-44986" title="CVE-2024-44986" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44987" id="CVE-2024-44987" title="CVE-2024-44987" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44988" id="CVE-2024-44988" title="CVE-2024-44988" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:net: USB: Fix wrong-direction WARNING in plusb.cThe syzbot fuzzer detected a bug in the plusb network driver: Azero-length control-OUT transfer was treated as a read instead of awrite.  In modern kernels this error provokes a WARNING:usb 1-1: BOGUS control dir, pipe 80000280 doesn&#39;t match bRequestType c0WARNING: CPU: 0 PID: 4645 at drivers/usb/core/urb.c:411usb_submit_urb+0x14a7/0x1880 drivers/usb/core/urb.c:411Modules linked in:CPU: 1 PID: 4645 Comm: dhcpcd Not tainted6.2.0-rc6-syzkaller-00050-g9f266ccaa2f5 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google01/12/2023RIP: 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/0xcdThe fix is to call usbnet_write_cmd() instead of usbnet_read_cmd() andremove the USB_DIR_IN flag.(CVE-2023-52742)In the Linux kernel, the following vulnerability has been resolved:media: dvb-usb-v2: af9035: Fix null-ptr-deref in af9035_i2c_master_xferIn af9035_i2c_master_xfer, msg is controlled by user. When msg[i].bufis null and msg[i].len is zero, former checks on msg[i].buf would bepassed. Malicious data finally reach af9035_i2c_master_xfer. If accessingmsg[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(&#34;media: dvb-usb: az6027: fix null-ptr-deref in az6027_i2c_xfer()&#34;)(CVE-2023-52915)In the Linux kernel, the following vulnerability has been resolved:media: aspeed: Fix memory overwrite if timing is 1600x900When capturing 1600x900, system could crash when system memory usage istight.The way to reproduce this issue:1. Use 1600x900 to display on host2. Mount ISO through &#39;Virtual media&#39; on OpenBMC&#39;s web3. Run script as below on host to do sha continuously  #!/bin/bash  while [ [1] ];  do&#x9;find /media -type f -printf &#39;&#34;%h/%f&#34;\n&#39; | xargs sha256sum  done4. Open KVM on OpenBMC&#39;s webThe size of macro block captured is 8x8. Therefore, we should make surethe height of src-buf is 8 aligned to fix this issue.(CVE-2023-52916)In the Linux kernel, the following vulnerability has been resolved:bna: ensure the copied buf is NUL terminatedCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes fromuserspace to that buffer. Later, we use sscanf on this buffer but we don&#39;tensure that the string is terminated inside the buffer, this can lead toOOB read when using sscanf. Fix this issue by using memdup_user_nulinstead of memdup_user.(CVE-2024-36934)In the Linux kernel, the following vulnerability has been resolved:wifi: nl80211: don&#39;t free NULL coalescing ruleIf the parsing fails, we can dereference a NULL pointer here.(CVE-2024-36941)In the Linux kernel, the following vulnerability has been resolved:drm/qxl: Add check for drm_cvt_modeAdd check for the return value of drm_cvt_mode() and return the error ifit fails in order to avoid NULL pointer dereference.(CVE-2024-43829)In the Linux kernel, the following vulnerability has been resolved:usb: gadget: core: Check for unset descriptorMake 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&#39;t properly set up the endpointfor the current speed, or the gadget descriptors are malformed andthe descriptor for the speed/endpoint are not found.No current gadget driver is known to have this problem, but thismay cause a hard-to-find bug during development of new gadgets.(CVE-2024-44960)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 freedand associated dst/idev could also have been freed.We need to hold rcu_read_lock() to make sure the dst andassociated idev are alive.(CVE-2024-44986)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 safelydereference rt, unless we hold rcu_read_lock().A similar issue has been fixed in commita688caa34beb (&#34;ipv6: take rcu lock in rawv6_send_hdrinc()&#34;)Another potential issue in ip6_finish_output2() is handled in aseparate patch.[1] BUG: KASAN: slab-use-after-free in ip6_send_skb+0x18d/0x230 net/ipv6/ip6_output.c:1964Read of size 8 at addr ffff88806dde4858 by task syz.1.380/6530CPU: 1 UID: 0 PID: 6530 Comm: syz.1.380 Not tainted 6.11.0-rc3-syzkaller-00306-gdf6cbc62cc9b #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 08/06/2024Call 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/0x7fRIP: 0033:0x7f936bf79e79Code: 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 48RSP: 002b:00007f936cd7f038 EFLAGS: 00000246 ORIG_RAX: 0000000000000014RAX: ffffffffffffffda RBX: 00007f936c115f80 RCX: 00007f936bf79e79RDX: 0000000000000001 RSI: 0000000020000040 RDI: 0000000000000004RBP: 00007f936bfe7916 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000246 R12: 0000000000000000R13: 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/0x7fFreed 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-2024-44987)In the Linux kernel, the following vulnerability has been resolved:net: dsa: mv88e6xxx: Fix out-of-bound accessIf an ATU violation was caused by a CPU Load operation, the SPID couldbe larger than DSA_MAX_PORTS (the size of mv88e6xxx_chip.ports[] array).(CVE-2024-44988)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.94.0.175.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.94.0.175.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.94.0.175.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2156</id>
          <title>An update for scsi-target-utils is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45751" id="CVE-2024-45751" title="CVE-2024-45751" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-45751)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="scsi-target-utils" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-1.0.79-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="scsi-target-utils-debuginfo" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-debuginfo-1.0.79-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="scsi-target-utils-debugsource" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-debugsource-1.0.79-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="scsi-target-utils-gluster" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-gluster-1.0.79-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="scsi-target-utils-rbd" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-rbd-1.0.79-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="scsi-target-utils-help" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-help-1.0.79-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-1.0.79-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils-debuginfo" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-debuginfo-1.0.79-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils-debugsource" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-debugsource-1.0.79-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils-gluster" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-gluster-1.0.79-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="scsi-target-utils-rbd" release="6.oe2203sp1" version="1.0.79">
                         <filename>scsi-target-utils-rbd-1.0.79-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2158</id>
          <title>An update for microcode_ctl is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-23984" id="CVE-2024-23984" title="CVE-2024-23984" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24968" id="CVE-2024-24968" title="CVE-2024-24968" type="cve"></reference>
          </references>
          <description>Observable discrepancy in RAPL interface for some Intel(R) Processors may allow a privileged user to potentially enable information disclosure via local access.(CVE-2024-23984)Improper finite state machines (FSMs) in hardware logic in some Intel(R) Processors may allow an privileged user to potentially enable a denial of service via local access.(CVE-2024-24968)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="x86_64" name="microcode_ctl" release="1.oe2203sp1" version="20240910">
                         <filename>microcode_ctl-20240910-1.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2159</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29508" id="CVE-2024-29508" title="CVE-2024-29508" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-29510" id="CVE-2024-29510" title="CVE-2024-29510" type="cve"></reference>
          </references>
          <description>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-29508)Artifex Ghostscript before 10.03.1 allows memory corruption, and SAFER sandbox bypass, via format string injection with a uniprint device.(CVE-2024-29510)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2165</id>
          <title>An update for three-eight-nine-ds-base is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-20"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-1949" id="CVE-2022-1949" title="CVE-2022-1949" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-5953" id="CVE-2024-5953" title="CVE-2024-5953" type="cve"></reference>
          </references>
          <description>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-2022-1949)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.(CVE-2024-5953)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="389-ds-base" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debuginfo" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-debugsource" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-devel" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-help" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-legacy-tools" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="389-ds-base-snmp" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cockpit-389-ds" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>cockpit-389-ds-1.4.3.36-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-lib389" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>python3-lib389-1.4.3.36-7.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-1.4.3.36-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debuginfo" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debuginfo-1.4.3.36-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-debugsource" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-debugsource-1.4.3.36-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-devel" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-devel-1.4.3.36-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-help" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-help-1.4.3.36-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-legacy-tools" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-legacy-tools-1.4.3.36-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="389-ds-base-snmp" release="7.oe2203sp1" version="1.4.3.36">
                         <filename>389-ds-base-snmp-1.4.3.36-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2173</id>
          <title>An update for nodejs is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-46809" id="CVE-2023-46809" title="CVE-2023-46809" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22019" id="CVE-2024-22019" title="CVE-2024-22019" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22025" id="CVE-2024-22025" title="CVE-2024-22025" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27982" id="CVE-2024-27982" title="CVE-2024-27982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27983" id="CVE-2024-27983" title="CVE-2024-27983" type="cve"></reference>
          </references>
          <description>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-2023-46809)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-22019)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-22025)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-27982)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.(CVE-2024-27983)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="nodejs" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debuginfo" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-debugsource" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-devel" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-full-i18n" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="nodejs-libs" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="npm" release="1.12.22.11.10.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="v8-devel" release="1.12.22.11.10.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="nodejs-docs" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-docs-12.22.11-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-12.22.11-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debuginfo" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debuginfo-12.22.11-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-debugsource" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-debugsource-12.22.11-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-devel" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-devel-12.22.11-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-full-i18n" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-full-i18n-12.22.11-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="nodejs-libs" release="10.oe2203sp1" version="12.22.11">
                         <filename>nodejs-libs-12.22.11-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="npm" release="1.12.22.11.10.oe2203sp1" version="6.14.16">
                         <filename>npm-6.14.16-1.12.22.11.10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="v8-devel" release="1.12.22.11.10.oe2203sp1" version="7.8.279.23">
                         <filename>v8-devel-7.8.279.23-1.12.22.11.10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2178</id>
          <title>An update for ghostscript is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52722" id="CVE-2023-52722" title="CVE-2023-52722" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33869" id="CVE-2024-33869" title="CVE-2024-33869" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33870" id="CVE-2024-33870" title="CVE-2024-33870" type="cve"></reference>
          </references>
          <description>An issue was discovered in Artifex Ghostscript before 10.03.1. psi/zmisc1.c, when SAFER mode is used, allows eexec seeds other than the Type 1 standard.(CVE-2023-52722)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-33869)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-33870)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ghostscript" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debuginfo" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-debugsource" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-devel" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ghostscript-tools-dvipdf" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-10.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="ghostscript-help" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-help-9.55.0-10.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debuginfo" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debuginfo-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-debugsource" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-debugsource-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-devel" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-devel-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ghostscript-tools-dvipdf" release="10.oe2203sp1" version="9.55.0">
                         <filename>ghostscript-tools-dvipdf-9.55.0-10.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2180</id>
          <title>An update for libpcap is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-7256" id="CVE-2023-7256" title="CVE-2023-7256" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8006" id="CVE-2024-8006" title="CVE-2024-8006" type="cve"></reference>
          </references>
          <description>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-2023-7256)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.(CVE-2024-8006)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="14" arch="aarch64" name="libpcap" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-1.10.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="14" arch="aarch64" name="libpcap-debuginfo" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-debuginfo-1.10.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="14" arch="aarch64" name="libpcap-debugsource" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-debugsource-1.10.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="14" arch="aarch64" name="libpcap-devel" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-devel-1.10.1-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="14" arch="noarch" name="libpcap-help" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-help-1.10.1-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="14" arch="x86_64" name="libpcap" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-1.10.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="14" arch="x86_64" name="libpcap-debuginfo" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-debuginfo-1.10.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="14" arch="x86_64" name="libpcap-debugsource" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-debugsource-1.10.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="14" arch="x86_64" name="libpcap-devel" release="4.oe2203sp1" version="1.10.1">
                         <filename>libpcap-devel-1.10.1-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2185</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48828" id="CVE-2022-48828" title="CVE-2022-48828" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48872" id="CVE-2022-48872" title="CVE-2022-48872" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52691" id="CVE-2023-52691" title="CVE-2023-52691" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52748" id="CVE-2023-52748" title="CVE-2023-52748" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52894" id="CVE-2023-52894" title="CVE-2023-52894" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52900" id="CVE-2023-52900" title="CVE-2023-52900" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36270" id="CVE-2024-36270" title="CVE-2024-36270" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36915" id="CVE-2024-36915" title="CVE-2024-36915" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38565" id="CVE-2024-38565" title="CVE-2024-38565" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41017" id="CVE-2024-41017" title="CVE-2024-41017" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41059" id="CVE-2024-41059" title="CVE-2024-41059" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41098" id="CVE-2024-41098" title="CVE-2024-41098" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42104" id="CVE-2024-42104" title="CVE-2024-42104" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42119" id="CVE-2024-42119" title="CVE-2024-42119" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42292" id="CVE-2024-42292" title="CVE-2024-42292" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44965" id="CVE-2024-44965" title="CVE-2024-44965" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44974" id="CVE-2024-44974" title="CVE-2024-44974" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44995" id="CVE-2024-44995" title="CVE-2024-44995" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44999" id="CVE-2024-44999" title="CVE-2024-44999" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45003" id="CVE-2024-45003" title="CVE-2024-45003" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45028" id="CVE-2024-45028" title="CVE-2024-45028" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46714" id="CVE-2024-46714" title="CVE-2024-46714" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46723" id="CVE-2024-46723" title="CVE-2024-46723" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46731" id="CVE-2024-46731" title="CVE-2024-46731" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46733" id="CVE-2024-46733" title="CVE-2024-46733" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46744" id="CVE-2024-46744" title="CVE-2024-46744" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46745" id="CVE-2024-46745" title="CVE-2024-46745" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46747" id="CVE-2024-46747" title="CVE-2024-46747" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46751" id="CVE-2024-46751" title="CVE-2024-46751" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46752" id="CVE-2024-46752" title="CVE-2024-46752" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46787" id="CVE-2024-46787" title="CVE-2024-46787" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:NFSD: Fix ia_size underflowiattr::ia_size is a loff_t, which is a signed 64-bit type. NFSv3 andNFSv4 both define file size as an unsigned 64-bit type. Thus thereis a range of valid file size values an NFS client can send that isalready larger than Linux can handle.Currently decode_fattr4() dumps a full u64 value into ia_size. Ifthat value happens to be larger than S64_MAX, then ia_sizeunderflows. I&#39;m about to fix up the NFSv3 behavior as well, so let&#39;scatch the underflow in the common code path: nfsd_setattr().(CVE-2022-48828)In the Linux kernel, the following vulnerability has been resolved:misc: fastrpc: Fix use-after-free race condition for mapsIt is possible that in between calling fastrpc_map_get() untilmap-&gt;fl-&gt;lock is taken in fastrpc_free_map(), another thread can callfastrpc_map_lookup() and get a reference to a map that is about to bedeleted.Rewrite fastrpc_map_get() to only increase the reference count of a mapif it&#39;s non-zero. Propagate this to callers so they can know if a map isabout 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-2022-48872)In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix a double-free in si_dpm_initWhen the allocation ofadev-&gt;pm.dpm.dyn_state.vddc_dependency_on_dispclk.entries fails,amdgpu_free_extended_power_table is called to free some fields of adev.However, when the control flow returns to si_dpm_sw_init, it goes tolabel dpm_failed and calls si_dpm_fini, which callsamdgpu_free_extended_power_table again and free those fields again. Thusa double-free is triggered.(CVE-2023-52691)In the Linux kernel, the following vulnerability has been resolved:f2fs: avoid format-overflow warningWith gcc and W=1 option, there&#39;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 between1 and 7 bytes into a region of size between 5 and 8[-Werror=format-overflow=] 1984 |  sprintf(slab_name, &#34;f2fs_page_array_entry-%u:%u&#34;, MAJOR(dev),&#x9;&#x9;MINOR(dev));      |                                               ^~String &#34;f2fs_page_array_entry-%u:%u&#34; can up to 35. The first &#34;%u&#34; can upto 4 and the second &#34;%u&#34; can up to 7, so total size is &#34;24 + 4 + 7 = 35&#34;.slab_name&#39;s size should be 35 rather than 32.(CVE-2023-52748)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&#39;ve received an (as yet) unreproduciblecrash 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.10The call stack is:  ncm_close() -&gt; ncm_notify() -&gt; ncm_do_notify()with the crash at:  ncm_do_notify+0x98/0x270Code: 79000d0b b9000a6c f940012a f9400269 (b9405d4b)Which I believe disassembles to (I don&#39;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&#39;re reading &#39;cdev-&gt;gadget&#39; 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 &#39;cdev-&gt;gadget&#39; 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_speedand hits a panic.AFAICT, if I&#39;m counting right, the offset of max_speed is indeed 0x5C.(remember there&#39;s a GKI KABI reservation of 16 bytes in struct work_struct)It&#39;s not at all clear to me how this is all supposed to work...but returning 0 seems much better than panic-ing...(CVE-2023-52894)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 nodeblock by calling __nilfs_btree_get_block() against an invalid virtualblock address, it returns -ENOENT because conversion of the virtual blockaddress to a disk block address fails.  However, this return value is thesame as the internal code that b-tree lookup routines return to indicatethat the block being searched does not exist, so functions that operate onthat b-tree may misbehave.When nilfs_btree_insert() receives this spurious &#39;not found&#39; code fromnilfs_btree_do_lookup(), it misunderstands that the &#39;not found&#39; check wassuccessful and continues the insert operation using incomplete lookup pathdata, 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 errorcode that __nilfs_btree_get_block() returns on block address conversionfailure from -ENOENT to another internal code -EINVAL which means that theb-tree metadata is corrupted.By returning -EINVAL, it propagates without glitches, and for all relevantb-tree operations, functions in the upper bmap layer output an errormessage indicating corrupted b-tree metadata vianilfs_bmap_convert_error(), and code -EIO will be eventually returned asit should be.(CVE-2023-52900)In the Linux kernel, the following vulnerability has been resolved:netfilter: tproxy: bail out if IP has been disabled on the devicesyzbot reports:general protection fault, probably for non-canonical address 0xdffffc0000000003: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000018-0x000000000000001f][..]RIP: 0010:nf_tproxy_laddr4+0xb7/0x340 net/ipv4/netfilter/nf_tproxy_ipv4.c:62Call 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-36270)In the Linux kernel, the following vulnerability has been resolved:nfc: llcp: fix nfc_llcp_setsockopt() unsafe copiessyzbot 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:255Read of size 4 at addr ffff88801caa1ec3 by task syz-executor459/5078CPU: 0 PID: 5078 Comm: syz-executor459 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024Call 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/0x75RIP: 0033:0x7f7fac07fd89Code: 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 48RSP: 002b:00007fff660eb788 EFLAGS: 00000246 ORIG_RAX: 0000000000000036RAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007f7fac07fd89RDX: 0000000000000000 RSI: 0000000000000118 RDI: 0000000000000004RBP: 0000000000000000 R08: 0000000000000002 R09: 0000000000000000R10: 0000000020000a80 R11: 0000000000000246 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000(CVE-2024-36915)In the Linux kernel, the following vulnerability has been resolved:wifi: ar5523: enable proper endpoint verificationSyzkaller reports [1] hitting a warning about an endpoint in usenot having an expected type to it.Fix the issue by checking for the existence of all properendpoints 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 1WARNING: 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-38565)In the Linux kernel, the following vulnerability has been resolved:jfs: don&#39;t walk off the end of ealistAdd a check before visiting the members of ea tomake sure each ea stays within the ealist.(CVE-2024-41017)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/0x7fUninit 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-41059)In the Linux kernel, the following vulnerability has been resolved:ata: libata-core: Fix null pointer dereference on errorIf 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 structmembers unconditionally, which can lead to the following:BUG: unable to handle page fault for address: 0000000000003990PGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP NOPTICPU: 10 PID: 594 Comm: (udev-worker) Not tainted 6.10.0-rc5 #44Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.16.3-2.fc40 04/01/2014RIP: 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 41RSP: 0018:ffffc90000ebb968 EFLAGS: 00010246RAX: 0000000000000041 RBX: ffff88810fb52e78 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff88813b3218c0 RDI: ffff88813b3218c0RBP: ffff88810fb52e40 R08: 0000000000000000 R09: 6c65725f74736f68R10: ffffc90000ebb738 R11: 73692033203a746e R12: 0000000000000004R13: 0000000000000000 R14: 0000000000000011 R15: 0000000000000006FS:  00007f6cc55b9980(0000) GS:ffff88813b300000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000003990 CR3: 00000001122a2000 CR4: 0000000000750ef0PKRU: 55555554Call 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-2024-41098)In the Linux kernel, the following vulnerability has been resolved:nilfs2: add missing check for inode numbers on directory entriesSyzbot reported that mounting and unmounting a specific pattern ofcorrupted nilfs2 filesystem images causes a use-after-free of metadatafile inodes, which triggers a kernel bug in lru_add_fn().As Jan Kara pointed out, this is because the link count of a metadata filegets 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 numbersof these metadata files that should not be visible in the namespace areread without checking.Fix this issue by treating the inode numbers of these internal files aserrors in the sanity check helper when reading directory folios/pages.Also thanks to Hillf Danton and Matthew Wilcox for their initial mm-layeranalysis.(CVE-2024-42104)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, italso 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-42119)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, sowill cause OOB memory access issue if variable MODALIAS is not the lastone within its @env parameter, fixed by correcting size to memmove.(CVE-2024-42292)In the Linux kernel, the following vulnerability has been resolved:x86/mm: Fix pti_clone_pgtable() alignment assumptionGuenter reported dodgy crashes on an i386-nosmp build using GCC-11that 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 onthe start address, notably it hard assumes start is PMD aligned. Thisis true on x86_64, but very much not true on i386.These assumptions can cause the end condition to malfunction, leadingto a &#39;short&#39; clone. Guess what happens when the user mapping has ashort copy of the entry text?Use the correct increment form for addr to avoid alignmentassumptions.(CVE-2024-44965)In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: avoid possible UaF when selecting endpselect_local_address() and select_signal_address() both select anendpoint entry from the list inside an RCU protected section, but returna reference to it, to be read later on. If the entry is dereferencedafter the RCU unlock, reading info could cause a Use-after-Free.A simple solution is to copy the required info while inside the RCUprotected section to avoid any risk of UaF later. The address ID mightneed to be modified later to handle the ID0 case later, so a copy seemsOK to deal with.(CVE-2024-44974)In the Linux kernel, the following vulnerability has been resolved:net: hns3: fix a deadlock problem when config TC during resettingWhen config TC during the reset process, may cause a deadlock, the flow isas 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 thiscase, the setup tc process will UP the port before UINIT, so cause theproblem. Adds a DOWN process in UINIT to fix it.(CVE-2024-44995)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;headbefore 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/0x7fUninit 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/0x7fCPU: 0 UID: 0 PID: 7115 Comm: syz.1.515 Not tainted 6.11.0-rc1-syzkaller-00043-g94ede2a3e913 #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/27/2024(CVE-2024-44999)In the Linux kernel, the following vulnerability has been resolved:vfs: Don&#39;t evict inode under the inode lru traversing contextThe inode reclaiming process(See function prune_icache_sb) collects allreclaimable inodes and mark them with I_FREEING flag at first, at thattime, other processes will be stuck if they try getting these inodes(See function find_inode_fast), then the reclaiming process destroy theinodes by function dispose_list(). Some filesystems(eg. ext4 withea_inode feature, ubifs with xattr) may do inode lookup in the inodeevicting callback function, if the inode lookup is operated under theinode 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&#x9;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&#39;s wbuf-&gt;io_mutex while getting the&#x9;xattr inode, which could race with inode reclaiming process(The        reclaiming process could try locking BASEHD&#39;s wbuf-&gt;io_mutex in&#x9;inode evicting function), then an ABBA deadlock problem would&#x9;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_ISOLATINGto pin the inode in memory while inode_lru_isolate(---truncated---(CVE-2024-45003)In the Linux kernel, the following vulnerability has been resolved:mmc: mmc_test: Fix NULL dereference on allocation failureIf the &#34;test-&gt;highmem = alloc_pages()&#34; allocation fails then calling__free_pages(test-&gt;highmem) will result in a NULL dereference.  Alsochange the error code to -ENOMEM instead of returning success.(CVE-2024-45028)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Skip wbscl_set_scaler_filter if filter is nullCallers can pass null in filter (i.e. from returned from the functionwbscl_get_filter_coeffs_16p) and a null check is added to ensure that isnot the case.This fixes 4 NULL_RETURNS issues reported by Coverity.(CVE-2024-46714)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: fix ucode out-of-bounds read warningClear warning that read ucode[] may out-of-bounds.(CVE-2024-46723)In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: fix the Out-of-bounds read warningusing index i - 1U may beyond element indexfor mc_data[] when i = 0.(CVE-2024-46731)In the Linux kernel, the following vulnerability has been resolved:btrfs: fix qgroup reserve leaks in cow_file_rangeIn the buffered write path, the dirty page owns the qgroup reserve untilit creates an ordered_extent.Therefore, any errors that occur before the ordered_extent is createdmust free that reservation, or else the space is leaked. The fstestgeneric/475 exercises various IO error paths, and is able to triggererrors in cow_file_range where we fail to get to allocating the orderedextent. Note that because we *do* clear delalloc, we are likely toremove the inode from the delalloc list, so the inodes/pages to not haveinvalidate/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 leakedCases 2 and 3 in the out_reserve path both pertain to this type of leakand must free the reserved qgroup data. Because it is already an errorpath, I opted not to handle the possible errors inbtrfs_free_qgroup_data.(CVE-2024-46733)In the Linux kernel, the following vulnerability has been resolved:Squashfs: sanity check symbolic link sizeSyzkiller reports a &#34;KMSAN: uninit-value in pick_link&#34; bug.This is caused by an uninitialised page, which is ultimately causedby a corrupted symbolic link size read from disk.The reason why the corrupted symlink size causes an uninitialisedpage 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 symboliclink size is not larger than expected.--V2: fix spelling mistake.(CVE-2024-46744)In the Linux kernel, the following vulnerability has been resolved:Input: uinput - reject requests with unreasonable number of slotsWhen exercising uinput interface syzkaller may try setting up devicewith a really large number of slots, which causes memory allocationfailure in input_mt_init_slots(). While this allocation failure ishandled properly and request is rejected, it results in syzkallerreports. Additionally, such request may put undue burden on thesystem 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 easilybe extended if we see devices that can track more than 100 contacts.(CVE-2024-46745)In the Linux kernel, the following vulnerability has been resolved:HID: cougar: fix slab-out-of-bounds Read in cougar_report_fixupreport_fixup for the Cougar 500k Gaming Keyboard was not verifyingthat the report descriptor size was correct before accessing it(CVE-2024-46747)In the Linux kernel, the following vulnerability has been resolved:btrfs: don&#39;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-46751)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 andabort the transaction in case we find an extent buffer belonging to therelocation tree that doesn&#39;t have the full backref flag set. This isunexpected and should never happen (save for bugs or a potential badmemory).(CVE-2024-46752)In the Linux kernel, the following vulnerability has been resolved:userfaultfd: fix checks for huge PMDsPatch series &#34;userfaultfd: fix races around pmd_trans_huge() check&#34;, v2.The pmd_trans_huge() code in mfill_atomic() is wrong in three differentways 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&#39;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&#39;t tested this case).2. As pointed out by Qi Zheng, pmd_trans_huge() is not sufficient for   detecting PMDs that don&#39;t point to page tables.   On older kernels (before 6.5), you&#39;d just have to win a single fairly   wide race to hit this.   I&#39;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&#39;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, onefix for bug 3), so that the first fix can be backported to kernelsaffected 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 (&#34;mm/pgtable: allowpte_offset_map[_lock]() to fail&#34;), this can&#39;t lead to anything worse thana BUG_ON(), since the page table access helpers are actually designed todeal with page tables concurrently disappearing; but on older kernels(&lt;=6.4), I think we could probably theoretically race past the twoBUG_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 typesof huge PMDs that pmd_trans_huge() can&#39;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 aPMD that contains a migration entry (which just requires winning a single,fairly wide race), it will pass the PMD to pte_offset_map_lock(), whichassumes that the PMD points to a page table.Breakage follows: First, the kernel tries to take the PTE lock (which willcrash or maybe worse if there is no &#34;struct page&#34; for the address bits inthe migration entry PMD - I think at least on X86 there usually is nocorresponding &#34;struct page&#34; thanks to the PTE inversion mitigation, amd64looks different).If that didn&#39;t crash, the kernel would next try to write a PTE into whatit 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&#39;s redundant, we&#39;re going to have to check forthat after the __pte_alloc() anyway.Backport note: pmdp_get_lockless() is pmd_read_atomic() in older kernels.(CVE-2024-46787)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.95.0.176.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.95.0.176.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.95.0.176.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2188</id>
          <title>An update for uboot-tools is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-2347" id="CVE-2022-2347" title="CVE-2022-2347" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-2347)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="uboot-images-elf" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-images-elf-2021.10-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-tools-2021.10-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools-debuginfo" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-tools-debuginfo-2021.10-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="uboot-tools-debugsource" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-tools-debugsource-2021.10-8.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="uboot-images-armv8" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-images-armv8-2021.10-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="uboot-tools-help" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-tools-help-2021.10-8.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-tools-2021.10-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools-debuginfo" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-tools-debuginfo-2021.10-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="uboot-tools-debugsource" release="8.oe2203sp1" version="2021.10">
                         <filename>uboot-tools-debugsource-2021.10-8.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2192</id>
          <title>An update for python3 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-6597" id="CVE-2023-6597" title="CVE-2023-6597" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3219" id="CVE-2024-3219" title="CVE-2024-3219" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6232" id="CVE-2024-6232" title="CVE-2024-6232" type="cve"></reference>
          </references>
          <description>An issue was found in the CPython `tempfile.TemporaryDirectory` class affecting versions 3.12.1, 3.11.7, 3.10.13, 3.9.18, and 3.8.18 and prior.The tempfile.TemporaryDirectory class would dereference symlinks during cleanup of permissions-related errors. This means users which can run privileged programs are potentially able to modify permissions of files referenced by symlinks in some circumstances.(CVE-2023-6597)There is a MEDIUM severity vulnerability affecting CPython.The “socket” module provides a pure-Python fallback to the socket.socketpair() function for platforms that don’t support AF_UNIX, such as Windows. This pure-Python implementation uses AF_INET or AF_INET6 to create a local connected pair of sockets. The connection between the two sockets was not verified before passing the two sockets back to the user, which leaves the server socket vulnerable to a connection race from a malicious local peer.Platforms that support AF_UNIX such as Linux and macOS are not affected by this vulnerability. Versions prior to CPython 3.5 are not affected due to the vulnerable API not being included.(CVE-2024-3219)There is a MEDIUM severity vulnerability affecting CPython.Regular expressions that allowed excessive backtracking during tarfile.TarFile header parsing are vulnerable to ReDoS via specifically-crafted tar archives.(CVE-2024-6232)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debug" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debuginfo" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-debugsource" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-devel" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-unversioned-command" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-help" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-help-3.9.9-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-3.9.9-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debug" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-debug-3.9.9-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debuginfo" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-debuginfo-3.9.9-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-debugsource" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-debugsource-3.9.9-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-devel" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-devel-3.9.9-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unversioned-command" release="32.oe2203sp1" version="3.9.9">
                         <filename>python3-unversioned-command-3.9.9-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2197</id>
          <title>An update for assimp is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45679" id="CVE-2024-45679" title="CVE-2024-45679" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-45679)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="assimp" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-5.2.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debuginfo" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-debugsource" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="assimp-devel" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-devel-5.2.4-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="assimp-help" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-help-5.2.4-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-assimp" release="3.oe2203sp1" version="5.2.4">
                         <filename>python3-assimp-5.2.4-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-5.2.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debuginfo" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-debuginfo-5.2.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-debugsource" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-debugsource-5.2.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="assimp-devel" release="3.oe2203sp1" version="5.2.4">
                         <filename>assimp-devel-5.2.4-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2201</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-6505" id="CVE-2024-6505" title="CVE-2024-6505" type="cve"></reference>
          </references>
          <description>A flaw was found in the virtio-net device in QEMU. When enabling the RSS feature on the virtio-net network card, the indirections_table data within RSS becomes controllable. Setting excessively large values may cause an index out-of-bounds issue, potentially resulting in heap overflow access. This flaw allows a privileged user in the guest to crash the QEMU process on the host.(CVE-2024-6505)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="10" arch="aarch64" name="qemu" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-curl" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-iscsi" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-rbd" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-block-ssh" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debuginfo" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-debugsource" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-guest-agent" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-hw-usb-host" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-img" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-aarch64" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-arm" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-riscv" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="aarch64" name="qemu-system-x86_64" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-99.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="10" arch="noarch" name="qemu-help" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-99.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-curl" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-iscsi" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-rbd" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-block-ssh" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debuginfo" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-debugsource" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-guest-agent" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-hw-usb-host" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-img" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-seabios" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-aarch64" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-arm" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-riscv" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="10" arch="x86_64" name="qemu-system-x86_64" release="99.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-99.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2202</id>
          <title>An update for ffmpeg is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31585" id="CVE-2024-31585" title="CVE-2024-31585" type="cve"></reference>
          </references>
          <description>FFmpeg version n5.1 to n6.1 was discovered to contain an Off-by-one Error vulnerability in libavfilter/avf_showspectrum.c. This vulnerability allows attackers to cause a Denial of Service (DoS) via a crafted input.(CVE-2024-31585)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="ffmpeg" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debuginfo" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-debugsource" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-devel" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="ffmpeg-libs" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libavdevice" release="18.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-18.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-4.2.4-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debuginfo" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debuginfo-4.2.4-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-debugsource" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-debugsource-4.2.4-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-devel" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-devel-4.2.4-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="ffmpeg-libs" release="18.oe2203sp1" version="4.2.4">
                         <filename>ffmpeg-libs-4.2.4-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libavdevice" release="18.oe2203sp1" version="4.2.4">
                         <filename>libavdevice-4.2.4-18.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2206</id>
          <title>An update for squid is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-09-27"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-25111" id="CVE-2024-25111" title="CVE-2024-25111" type="cve"></reference>
          </references>
          <description>Squid is a web proxy cache. Starting in version 3.5.27 and prior to version 6.8, Squid may be vulnerable to a Denial of Service attack against HTTP Chunked decoder due to an uncontrolled recursion bug. This problem allows a remote attacker to cause Denial of Service when sending a crafted, chunked, encoded HTTP Message. This bug is fixed in Squid version 6.8. In addition, patches addressing this problem for the stable releases can be found in Squid&#39;s patch archives. There is no workaround for this issue.(CVE-2024-25111)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="7" arch="aarch64" name="squid" release="26.oe2203sp1" version="4.9">
                         <filename>squid-4.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debuginfo" release="26.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="aarch64" name="squid-debugsource" release="26.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-26.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid" release="26.oe2203sp1" version="4.9">
                         <filename>squid-4.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debuginfo" release="26.oe2203sp1" version="4.9">
                         <filename>squid-debuginfo-4.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="7" arch="x86_64" name="squid-debugsource" release="26.oe2203sp1" version="4.9">
                         <filename>squid-debugsource-4.9-26.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2215</id>
          <title>An update for zlog is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-22857" id="CVE-2024-22857" title="CVE-2024-22857" type="cve"></reference>
          </references>
          <description>Heap based buffer flow in zlog v1.1.0 to v1.2.17 in zlog_rule_new().The size of record_name is MAXLEN_PATH(1024) + 1 but file_path may have data upto MAXLEN_CFG_LINE(MAXLEN_PATH*4) + 1. So a check was missing in zlog_rule_new() while copying the record_name from file_path + 1 which caused the buffer overflow. An attacker can exploit this vulnerability to overwrite the zlog_record_fn record_func function pointer to get arbitrary code execution or potentially cause remote code execution (RCE).(CVE-2024-22857)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="zlog" release="6.oe2203sp1" version="1.2.15">
                         <filename>zlog-1.2.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zlog-debuginfo" release="6.oe2203sp1" version="1.2.15">
                         <filename>zlog-debuginfo-1.2.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="zlog-debugsource" release="6.oe2203sp1" version="1.2.15">
                         <filename>zlog-debugsource-1.2.15-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zlog" release="6.oe2203sp1" version="1.2.15">
                         <filename>zlog-1.2.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zlog-debuginfo" release="6.oe2203sp1" version="1.2.15">
                         <filename>zlog-debuginfo-1.2.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="zlog-debugsource" release="6.oe2203sp1" version="1.2.15">
                         <filename>zlog-debugsource-1.2.15-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2218</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-27436" id="CVE-2024-27436" title="CVE-2024-27436" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36894" id="CVE-2024-36894" title="CVE-2024-36894" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38560" id="CVE-2024-38560" title="CVE-2024-38560" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38659" id="CVE-2024-38659" title="CVE-2024-38659" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39482" id="CVE-2024-39482" title="CVE-2024-39482" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-39501" id="CVE-2024-39501" title="CVE-2024-39501" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40978" id="CVE-2024-40978" title="CVE-2024-40978" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41030" id="CVE-2024-41030" title="CVE-2024-41030" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-41095" id="CVE-2024-41095" title="CVE-2024-41095" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43846" id="CVE-2024-43846" title="CVE-2024-43846" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43863" id="CVE-2024-43863" title="CVE-2024-43863" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43900" id="CVE-2024-43900" title="CVE-2024-43900" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44939" id="CVE-2024-44939" title="CVE-2024-44939" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44954" id="CVE-2024-44954" title="CVE-2024-44954" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44958" id="CVE-2024-44958" title="CVE-2024-44958" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44982" id="CVE-2024-44982" title="CVE-2024-44982" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45008" id="CVE-2024-45008" title="CVE-2024-45008" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45016" id="CVE-2024-45016" title="CVE-2024-45016" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45025" id="CVE-2024-45025" title="CVE-2024-45025" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46673" id="CVE-2024-46673" title="CVE-2024-46673" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46674" id="CVE-2024-46674" title="CVE-2024-46674" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46679" id="CVE-2024-46679" title="CVE-2024-46679" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46681" id="CVE-2024-46681" title="CVE-2024-46681" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46695" id="CVE-2024-46695" title="CVE-2024-46695" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46707" id="CVE-2024-46707" title="CVE-2024-46707" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46721" id="CVE-2024-46721" title="CVE-2024-46721" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46725" id="CVE-2024-46725" title="CVE-2024-46725" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46726" id="CVE-2024-46726" title="CVE-2024-46726" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46732" id="CVE-2024-46732" title="CVE-2024-46732" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46737" id="CVE-2024-46737" title="CVE-2024-46737" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46738" id="CVE-2024-46738" title="CVE-2024-46738" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46739" id="CVE-2024-46739" title="CVE-2024-46739" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46740" id="CVE-2024-46740" title="CVE-2024-46740" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46742" id="CVE-2024-46742" title="CVE-2024-46742" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46743" id="CVE-2024-46743" title="CVE-2024-46743" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46750" id="CVE-2024-46750" title="CVE-2024-46750" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46753" id="CVE-2024-46753" title="CVE-2024-46753" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46755" id="CVE-2024-46755" title="CVE-2024-46755" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46756" id="CVE-2024-46756" title="CVE-2024-46756" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46758" id="CVE-2024-46758" title="CVE-2024-46758" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46759" id="CVE-2024-46759" title="CVE-2024-46759" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46761" id="CVE-2024-46761" title="CVE-2024-46761" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46771" id="CVE-2024-46771" title="CVE-2024-46771" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46777" id="CVE-2024-46777" title="CVE-2024-46777" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46780" id="CVE-2024-46780" title="CVE-2024-46780" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46781" id="CVE-2024-46781" title="CVE-2024-46781" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46791" id="CVE-2024-46791" title="CVE-2024-46791" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46798" id="CVE-2024-46798" title="CVE-2024-46798" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46800" id="CVE-2024-46800" title="CVE-2024-46800" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46804" id="CVE-2024-46804" title="CVE-2024-46804" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46814" id="CVE-2024-46814" title="CVE-2024-46814" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46816" id="CVE-2024-46816" title="CVE-2024-46816" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46818" id="CVE-2024-46818" title="CVE-2024-46818" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46821" id="CVE-2024-46821" title="CVE-2024-46821" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46829" id="CVE-2024-46829" title="CVE-2024-46829" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46841" id="CVE-2024-46841" title="CVE-2024-46841" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46844" id="CVE-2024-46844" title="CVE-2024-46844" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46849" id="CVE-2024-46849" title="CVE-2024-46849" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46857" id="CVE-2024-46857" title="CVE-2024-46857" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:ALSA: usb-audio: Stop parsing channels bits when all channels are found.If a usb audio device sets more bits than the amount of channelsit could write outside of the map array.(CVE-2024-27436)In the Linux kernel, the following vulnerability has been resolved:usb: gadget: f_fs: Fix race between aio_cancel() and AIO request completeFFS based applications can utilize the aio_cancel() callback to dequeuepending USB requests submitted to the UDC.  There is a scenario where theFFS application issues an AIO cancel call, while the UDC is handling asoft disconnect.  For a DWC3 based implementation, the callstack lookslike the following:    DWC3 Gadget                               FFS Applicationdwc3_gadget_soft_disconnect()              ...  --&gt; dwc3_stop_active_transfers()    --&gt; dwc3_gadget_giveback(-ESHUTDOWN)      --&gt; ffs_epfile_async_io_complete()   ffs_aio_cancel()        --&gt; usb_ep_free_request()            --&gt; usb_ep_dequeue()There is currently no locking implemented between the AIO completionhandler and AIO cancel, so the issue occurs if the completion routine isrunning in parallel to an AIO cancel call coming from the FFS application.As the completion call frees the USB request (io_data-&gt;req) the FFSapplication is also referencing it for the usb_ep_dequeue() call.  This canlead to accessing a stale/hanging pointer.commit b566d38857fc (&#34;usb: gadget: f_fs: use io_data-&gt;status consistently&#34;)relocated the usb_ep_free_request() into ffs_epfile_async_io_complete().However, in order to properly implement locking to mitigate this issue, thespinlock can&#39;t be added to ffs_epfile_async_io_complete(), asusb_ep_dequeue() (if successfully dequeuing a USB request) will call thefunction driver&#39;s completion handler in the same context.  Hence, leadinginto a deadlock.Fix this issue by moving the usb_ep_free_request() back toffs_user_copy_worker(), and ensuring that it explicitly sets io_data-&gt;reqto NULL after freeing it within the ffs-&gt;eps_lock.  This resolves the racecondition above, as the ffs_aio_cancel() routine will not continueattempting to dequeue a request that has already been freed, or theffs_user_copy_work() not freeing the USB request until the AIO cancel isdone referencing it.This fix depends on  commit b566d38857fc (&#34;usb: gadget: f_fs: use io_data-&gt;status  consistently&#34;)(CVE-2024-36894)In the Linux kernel, the following vulnerability has been resolved:scsi: bfa: Ensure the copied buf is NUL terminatedCurrently, we allocate a nbytes-sized kernel buffer and copy nbytes fromuserspace to that buffer. Later, we use sscanf on this buffer but we don&#39;tensure that the string is terminated inside the buffer, this can lead toOOB read when using sscanf. Fix this issue by using memdup_user_nul insteadof memdup_user.(CVE-2024-38560)In the Linux kernel, the following vulnerability has been resolved:enic: Validate length of nl attributes in enic_set_vf_portenic_set_vf_port assumes that the nl attribute IFLA_PORT_PROFILEis of length PORT_PROFILE_MAX and that the nl attributesIFLA_PORT_INSTANCE_UUID, IFLA_PORT_HOST_UUID are of length PORT_UUID_MAX.These attributes are validated (in the function do_setlink in rtnetlink.c)using the nla_policy ifla_port_policy. The policy defines IFLA_PORT_PROFILEas NLA_STRING, IFLA_PORT_INSTANCE_UUID as NLA_BINARY andIFLA_PORT_HOST_UUID as NLA_STRING. That means that the length validationusing the policy is for the max size of the attributes and not on exactsize so the length of these attributes might be less than the sizes thatenic_set_vf_port expects. This might cause an out of bandsread access in the memcpys of the data of theseattributes in enic_set_vf_port.(CVE-2024-38659)In the Linux kernel, the following vulnerability has been resolved:bcache: fix variable length array abuse in btree_iterbtree_iter is used in two ways: either allocated on the stack with afixed size MAX_BSETS, or from a mempool with a dynamic size based on thespecific cache set. Previously, the struct had a fixed-length array ofsize MAX_BSETS which was indexed out-of-bounds for the dynamically-sizediterators, which causes UBSAN to complain.This patch uses the same approach as in bcachefs&#39;s sort_iter and splitsthe iterator into a btree_iter with a flexible array member and abtree_iter_stack which embeds a btree_iter as well as a fixed-lengthdata array.(CVE-2024-39482)In the Linux kernel, the following vulnerability has been resolved:drivers: core: synchronize really_probe() and dev_uevent()Synchronize the dev-&gt;driver usage in really_probe() and dev_uevent().These can run in different threads, what can result in the followingrace condition for dev-&gt;driver uninitialization:Thread #1:==========really_probe() {...probe_failed:...device_unbind_cleanup(dev) {    ...    dev-&gt;driver = NULL;   // &lt;= Failed probe sets dev-&gt;driver to NULL    ...    }...}Thread #2:==========dev_uevent() {...if (dev-&gt;driver)      // If dev-&gt;driver is NULLed from really_probe() from here on,      // after above check, the system crashes      add_uevent_var(env, &#34;DRIVER=%s&#34;, dev-&gt;driver-&gt;name);...}really_probe() holds the lock, already. So nothing needs to be donethere. dev_uevent() is called with lock held, often, too. But notalways. What implies that we can&#39;t add any locking in dev_uevent()itself. So fix this race by adding the lock to the non-protectedpath. This is the path where above race is observed: dev_uevent+0x235/0x380 uevent_show+0x10c/0x1f0  &lt;= Add lock here dev_attr_show+0x3a/0xa0 sysfs_kf_seq_show+0x17c/0x250 kernfs_seq_show+0x7c/0x90 seq_read_iter+0x2d7/0x940 kernfs_fop_read_iter+0xc6/0x310 vfs_read+0x5bc/0x6b0 ksys_read+0xeb/0x1b0 __x64_sys_read+0x42/0x50 x64_sys_call+0x27ad/0x2d30 do_syscall_64+0xcd/0x1d0 entry_SYSCALL_64_after_hwframe+0x77/0x7fSimilar cases are reported by syzkaller inhttps://syzkaller.appspot.com/bug?extid=ffa8143439596313a85aBut these are regarding the *initialization* of dev-&gt;driverdev-&gt;driver = drv;As this switches dev-&gt;driver to non-NULL these reports can be consideredto be false-positives (which should be &#34;fixed&#34; by this commit, as well,though).The same issue was reported and tried to be fixed back in 2015 inhttps://lore.kernel.org/lkml/1421259054-2574-1-git-send-email-a.sangwan@samsung.com/already.(CVE-2024-39501)In the Linux kernel, the following vulnerability has been resolved:scsi: qedi: Fix crash while reading debugfs attributeThe qedi_dbg_do_not_recover_cmd_read() function invokes sprintf() directlyon a __user pointer, which results into the crash.To fix this issue, use a small local stack buffer for sprintf() and thencall simple_read_from_buffer(), which in turns make the copy_to_user()call.BUG: unable to handle page fault for address: 00007f4801111000PGD 8000000864df6067 P4D 8000000864df6067 PUD 864df7067 PMD 846028067 PTE 0Oops: 0002 [#1] PREEMPT SMP PTIHardware name: HPE ProLiant DL380 Gen10/ProLiant DL380 Gen10, BIOS U30 06/15/2023RIP: 0010:memcpy_orig+0xcd/0x130RSP: 0018:ffffb7a18c3ffc40 EFLAGS: 00010202RAX: 00007f4801111000 RBX: 00007f4801111000 RCX: 000000000000000fRDX: 000000000000000f RSI: ffffffffc0bfd7a0 RDI: 00007f4801111000RBP: ffffffffc0bfd7a0 R08: 725f746f6e5f6f64 R09: 3d7265766f636572R10: ffffb7a18c3ffd08 R11: 0000000000000000 R12: 00007f4881110fffR13: 000000007fffffff R14: ffffb7a18c3ffca0 R15: ffffffffc0bfd7afFS:  00007f480118a740(0000) GS:ffff98e38af00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00007f4801111000 CR3: 0000000864b8e001 CR4: 00000000007706e0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400PKRU: 55555554Call Trace: &lt;TASK&gt; ? __die_body+0x1a/0x60 ? page_fault_oops+0x183/0x510 ? exc_page_fault+0x69/0x150 ? asm_exc_page_fault+0x22/0x30 ? memcpy_orig+0xcd/0x130 vsnprintf+0x102/0x4c0 sprintf+0x51/0x80 qedi_dbg_do_not_recover_cmd_read+0x2f/0x50 [qedi 6bcfdeeecdea037da47069eca2ba717c84a77324] full_proxy_read+0x50/0x80 vfs_read+0xa5/0x2e0 ? folio_add_new_anon_rmap+0x44/0xa0 ? set_pte_at+0x15/0x30 ? do_pte_missing+0x426/0x7f0 ksys_read+0xa5/0xe0 do_syscall_64+0x58/0x80 ? __count_memcg_events+0x46/0x90 ? count_memcg_event_mm+0x3d/0x60 ? handle_mm_fault+0x196/0x2f0 ? do_user_addr_fault+0x267/0x890 ? exc_page_fault+0x69/0x150 entry_SYSCALL_64_after_hwframe+0x72/0xdcRIP: 0033:0x7f4800f20b4d(CVE-2024-40978)In the Linux kernel, the following vulnerability has been resolved:ksmbd: discard write access to the directory openmay_open() does not allow a directory to be opened with the write access.However, some writing flags set by client result in adding write accesson server, making ksmbd incompatible with FUSE file system. Simply, let&#39;sdiscard the write access when opening a directory.list_add corruption. next is NULL.------------[ cut here ]------------kernel BUG at lib/list_debug.c:26!pc : __list_add_valid+0x88/0xbclr : __list_add_valid+0x88/0xbcCall trace:__list_add_valid+0x88/0xbcfuse_finish_open+0x11c/0x170fuse_open_common+0x284/0x5e8fuse_dir_open+0x14/0x24do_dentry_open+0x2a4/0x4e0dentry_open+0x50/0x80smb2_open+0xbe4/0x15a4handle_ksmbd_work+0x478/0x5ecprocess_one_work+0x1b4/0x448worker_thread+0x25c/0x430kthread+0x104/0x1d4ret_from_fork+0x10/0x20(CVE-2024-41030)In the Linux kernel, the following vulnerability has been resolved:drm/nouveau/dispnv04: fix null pointer dereference in nv17_tv_get_ld_modesIn nv17_tv_get_ld_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-41095)In the Linux kernel, the following vulnerability has been resolved:lib: objagg: Fix general protection faultThe library supports aggregation of objects into other objects only ifthe parent object does not have a parent itself. That is, nesting is notsupported.Aggregation happens in two cases: Without and with hints, where hintsare a pre-computed recommendation on how to aggregate the providedobjects.Nesting is not possible in the first case due to a check that preventsit, but in the second case there is no check because the assumption isthat nesting cannot happen when creating objects based on hints. Theviolation of this assumption leads to various warnings and eventually toa general protection fault [1].Before fixing the root cause, error out when nesting happens and warn.[1]general protection fault, probably for non-canonical address 0xdead000000000d90: 0000 [#1] PREEMPT SMP PTICPU: 1 PID: 1083 Comm: kworker/1:9 Tainted: G        W          6.9.0-rc6-custom-gd9b4f1cca7fb #7Hardware name: Mellanox Technologies Ltd. MSN3700/VMOD0005, BIOS 5.11 01/06/2019Workqueue: mlxsw_core mlxsw_sp_acl_tcam_vregion_rehash_workRIP: 0010:mlxsw_sp_acl_erp_bf_insert+0x25/0x80[...]Call Trace: &lt;TASK&gt; mlxsw_sp_acl_atcam_entry_add+0x256/0x3c0 mlxsw_sp_acl_tcam_entry_create+0x5e/0xa0 mlxsw_sp_acl_tcam_vchunk_migrate_one+0x16b/0x270 mlxsw_sp_acl_tcam_vregion_rehash_work+0xbe/0x510 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-43846)In the Linux kernel, the following vulnerability has been resolved:drm/vmwgfx: Fix a deadlock in dma buf fence pollingIntroduce a version of the fence ops that on release doesn&#39;t removethe fence from the pending list, and thus doesn&#39;t require a lock tofix poll-&gt;fence wait-&gt;fence unref deadlocks.vmwgfx overwrites the wait callback to iterate over the list of allfences and update their status, to do that it holds a lock to preventthe list modifcations from other threads. The fence destroy callbackboth deletes the fence and removes it from the list of pendingfences, for which it holds a lock.dma buf polling cb unrefs a fence after it&#39;s been signaled: so the pollcalls the wait, which signals the fences, which are being destroyed.The destruction tries to acquire the lock on the pending fences listwhich it can never get because it&#39;s held by the wait from which itwas called.Old bug, but not a lot of userspace apps were using dma-buf pollinginterfaces. Fix those, in particular this fixes KDE stalls/deadlock.(CVE-2024-43863)In the Linux kernel, the following vulnerability has been resolved:media: xc2028: avoid use-after-free in load_firmware_cb()syzkaller reported use-after-free in load_firmware_cb() [1].The reason is because the module allocated a struct tuner in tuner_probe(),and then the module initialization failed, the struct tuner was released.A worker which created during module initialization accesses this structtuner later, it caused use-after-free.The process is as follows:task-6504           worker_threadtuner_probe                             &lt;= alloc dvb_frontend [2]...request_firmware_nowait                 &lt;= create a worker...tuner_remove                            &lt;= free dvb_frontend...                    request_firmware_work_func  &lt;= the firmware is ready                    load_firmware_cb    &lt;= but now the dvb_frontend has been freedTo fix the issue, check the dvd_frontend in load_firmware_cb(), if it isnull, report a warning and just return.[1]:    ==================================================================     BUG: KASAN: use-after-free in load_firmware_cb+0x1310/0x17a0     Read of size 8 at addr ffff8000d7ca2308 by task kworker/2:3/6504     Call trace:      load_firmware_cb+0x1310/0x17a0      request_firmware_work_func+0x128/0x220      process_one_work+0x770/0x1824      worker_thread+0x488/0xea0      kthread+0x300/0x430      ret_from_fork+0x10/0x20     Allocated by task 6504:      kzalloc      tuner_probe+0xb0/0x1430      i2c_device_probe+0x92c/0xaf0      really_probe+0x678/0xcd0      driver_probe_device+0x280/0x370      __device_attach_driver+0x220/0x330      bus_for_each_drv+0x134/0x1c0      __device_attach+0x1f4/0x410      device_initial_probe+0x20/0x30      bus_probe_device+0x184/0x200      device_add+0x924/0x12c0      device_register+0x24/0x30      i2c_new_device+0x4e0/0xc44      v4l2_i2c_new_subdev_board+0xbc/0x290      v4l2_i2c_new_subdev+0xc8/0x104      em28xx_v4l2_init+0x1dd0/0x3770     Freed by task 6504:      kfree+0x238/0x4e4      tuner_remove+0x144/0x1c0      i2c_device_remove+0xc8/0x290      __device_release_driver+0x314/0x5fc      device_release_driver+0x30/0x44      bus_remove_device+0x244/0x490      device_del+0x350/0x900      device_unregister+0x28/0xd0      i2c_unregister_device+0x174/0x1d0      v4l2_device_unregister+0x224/0x380      em28xx_v4l2_init+0x1d90/0x3770     The buggy address belongs to the object at ffff8000d7ca2000      which belongs to the cache kmalloc-2k of size 2048     The buggy address is located 776 bytes inside of      2048-byte region [ffff8000d7ca2000, ffff8000d7ca2800)     The buggy address belongs to the page:     page:ffff7fe00035f280 count:1 mapcount:0 mapping:ffff8000c001f000 index:0x0     flags: 0x7ff800000000100(slab)     raw: 07ff800000000100 ffff7fe00049d880 0000000300000003 ffff8000c001f000     raw: 0000000000000000 0000000080100010 00000001ffffffff 0000000000000000     page dumped because: kasan: bad access detected     Memory state around the buggy address:      ffff8000d7ca2200: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb      ffff8000d7ca2280: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb     &gt;ffff8000d7ca2300: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb                           ^      ffff8000d7ca2380: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb      ffff8000d7ca2400: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb     ==================================================================[2]    Actually, it is allocated for struct tuner, and dvb_frontend is inside.(CVE-2024-43900)In the Linux kernel, the following vulnerability has been resolved:jfs: fix null ptr deref in dtInsertEntry[syzbot reported]general protection fault, probably for non-canonical address 0xdffffc0000000001: 0000 [#1] PREEMPT SMP KASAN PTIKASAN: null-ptr-deref in range [0x0000000000000008-0x000000000000000f]CPU: 0 PID: 5061 Comm: syz-executor404 Not tainted 6.8.0-syzkaller-08951-gfe46a7dd189e #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 03/27/2024RIP: 0010:dtInsertEntry+0xd0c/0x1780 fs/jfs/jfs_dtree.c:3713...[Analyze]In dtInsertEntry(), when the pointer h has the same value as p, after writingname in UniStrncpy_to_le(), p-&gt;header.flag will be cleared. This will cause thepreviously true judgment &#34;p-&gt;header.flag &amp; BT-LEAF&#34; to change to no after writingthe name operation, this leads to entering an incorrect branch and accessing theuninitialized object ih when judging this condition for the second time.[Fix]After got the page, check freelist first, if freelist == 0 then exit dtInsert()and return -EINVAL.(CVE-2024-44939)In the Linux kernel, the following vulnerability has been resolved:ALSA: line6: Fix racy access to midibufThere can be concurrent accesses to line6 midibuf from both the URBcompletion callback and the rawmidi API access.  This could be a causeof KMSAN warning triggered by syzkaller below (so put as reported-byhere).This patch protects the midibuf call of the former code path with aspinlock for avoiding the possible races.(CVE-2024-44954)In the Linux kernel, the following vulnerability has been resolved:sched/smt: Fix unbalance sched_smt_present dec/incI got the following warn report while doing stress test:jump label: negative count!WARNING: CPU: 3 PID: 38 at kernel/jump_label.c:263 static_key_slow_try_dec+0x9d/0xb0Call Trace: &lt;TASK&gt; __static_key_slow_dec_cpuslocked+0x16/0x70 sched_cpu_deactivate+0x26e/0x2a0 cpuhp_invoke_callback+0x3ad/0x10d0 cpuhp_thread_fun+0x3f5/0x680 smpboot_thread_fn+0x56d/0x8d0 kthread+0x309/0x400 ret_from_fork+0x41/0x70 ret_from_fork_asm+0x1b/0x30 &lt;/TASK&gt;Because when cpuset_cpu_inactive() fails in sched_cpu_deactivate(),the cpu offline failed, but sched_smt_present is decremented beforecalling sched_cpu_deactivate(), it leads to unbalanced dec/inc, sofix it by incrementing sched_smt_present in the error path.(CVE-2024-44958)In the Linux kernel, the following vulnerability has been resolved:drm/msm/dpu: cleanup FB if dpu_format_populate_layout failsIf the dpu_format_populate_layout() fails, then FB is prepared, but notcleaned up. This ends up leaking the pin_count on the GEM object andcauses a splat during DRM file closure:msm_obj-&gt;pin_countWARNING: CPU: 2 PID: 569 at drivers/gpu/drm/msm/msm_gem.c:121 update_lru_locked+0xc4/0xcc[...]Call trace: update_lru_locked+0xc4/0xcc put_pages+0xac/0x100 msm_gem_free_object+0x138/0x180 drm_gem_object_free+0x1c/0x30 drm_gem_object_handle_put_unlocked+0x108/0x10c drm_gem_object_release_handle+0x58/0x70 idr_for_each+0x68/0xec drm_gem_release+0x28/0x40 drm_file_free+0x174/0x234 drm_release+0xb0/0x160 __fput+0xc0/0x2c8 __fput_sync+0x50/0x5c __arm64_sys_close+0x38/0x7c invoke_syscall+0x48/0x118 el0_svc_common.constprop.0+0x40/0xe0 do_el0_svc+0x1c/0x28 el0_svc+0x4c/0x120 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194irq event stamp: 129818hardirqs last  enabled at (129817): [&lt;ffffa5f6d953fcc0&gt;] console_unlock+0x118/0x124hardirqs last disabled at (129818): [&lt;ffffa5f6da7dcf04&gt;] el1_dbg+0x24/0x8csoftirqs last  enabled at (129808): [&lt;ffffa5f6d94afc18&gt;] handle_softirqs+0x4c8/0x4e8softirqs last disabled at (129785): [&lt;ffffa5f6d94105e4&gt;] __do_softirq+0x14/0x20Patchwork: https://patchwork.freedesktop.org/patch/600714/(CVE-2024-44982)In the Linux kernel, the following vulnerability has been resolved:Input: MT - limit max slotssyzbot is reporting too large allocation at input_mt_init_slots(), fornum_slots is supplied from userspace using ioctl(UI_DEV_CREATE).Since nobody knows possible max slots, this patch chose 1024.(CVE-2024-45008)In the Linux kernel, the following vulnerability has been resolved:netem: fix return value if duplicate enqueue failsThere is a bug in netem_enqueue() introduced bycommit 5845f706388a (&#34;net: netem: fix skb length BUG_ON in __skb_to_sgvec&#34;)that can lead to a use-after-free.This commit made netem_enqueue() always return NET_XMIT_SUCCESSwhen a packet is duplicated, which can cause the parent qdisc&#39;s q.qlento be mistakenly incremented. When this happens qlen_notify() may beskipped on the parent during destruction, leaving a dangling pointerfor some classful qdiscs like DRR.There are two ways for the bug happen:- If the duplicated packet is dropped by rootq-&gt;enqueue() and then  the original packet is also dropped.- If rootq-&gt;enqueue() sends the duplicated packet to a different qdisc  and the original packet is dropped.In both cases NET_XMIT_SUCCESS is returned even though no packetsare enqueued at the netem qdisc.The fix is to defer the enqueue of the duplicate packet until afterthe original packet has been guaranteed to return NET_XMIT_SUCCESS.(CVE-2024-45016)In the Linux kernel, the following vulnerability has been resolved:fix bitmap corruption on close_range() with CLOSE_RANGE_UNSHAREcopy_fd_bitmaps(new, old, count) is expected to copy the firstcount/BITS_PER_LONG bits from old-&gt;full_fds_bits[] and fillthe rest with zeroes.  What it does is copying enough words(BITS_TO_LONGS(count/BITS_PER_LONG)), then memsets the rest.That works fine, *if* all bits past the cutoff point areclear.  Otherwise we are risking garbage from the last wordwe&#39;d copied.For most of the callers that is true - expand_fdtable() hascount equal to old-&gt;max_fds, so there&#39;s no open descriptorspast count, let alone fully occupied words in -&gt;open_fds[],which is what bits in -&gt;full_fds_bits[] correspond to.The other caller (dup_fd()) passes sane_fdtable_size(old_fdt, max_fds),which is the smallest multiple of BITS_PER_LONG that covers allopened descriptors below max_fds.  In the common case (copying onfork()) max_fds is ~0U, so all opened descriptors will be belowit and we are fine, by the same reasons why the call in expand_fdtable()is safe.Unfortunately, there is a case where max_fds is less than thatand where we might, indeed, end up with junk in -&gt;full_fds_bits[] -close_range(from, to, CLOSE_RANGE_UNSHARE) with&#x9;* descriptor table being currently shared&#x9;* &#39;to&#39; being above the current capacity of descriptor table&#x9;* &#39;from&#39; being just under some chunk of opened descriptors.In that case we end up with observably wrong behaviour - e.g. spawna child with CLONE_FILES, get all descriptors in range 0..127 open,then close_range(64, ~0U, CLOSE_RANGE_UNSHARE) and watch dup(0) endingup with descriptor #128, despite #64 being observably not open.The minimally invasive fix would be to deal with that in dup_fd().If this proves to add measurable overhead, we can go that way, butlet&#39;s try to fix copy_fd_bitmaps() first.* new helper: bitmap_copy_and_expand(to, from, bits_to_copy, size).* make copy_fd_bitmaps() take the bitmap size in words, rather thanbits; it&#39;s &#39;count&#39; argument is always a multiple of BITS_PER_LONG,so we are not losing any information, and that way we can use thesame helper for all three bitmaps - compiler will see that countis a multiple of BITS_PER_LONG for the large ones, so it&#39;ll generateplain memcpy()+memset().Reproducer added to tools/testing/selftests/core/close_range_test.c(CVE-2024-45025)In the Linux kernel, the following vulnerability has been resolved:scsi: aacraid: Fix double-free on probe failureaac_probe_one() calls hardware-specific init functions through theaac_driver_ident::init pointer, all of which eventually call down toaac_init_adapter().If aac_init_adapter() fails after allocating memory for aac_dev::queues,it frees the memory but does not clear that member.After the hardware-specific init function returns an error,aac_probe_one() goes down an error path that frees the memory pointed toby aac_dev::queues, resulting.in a double-free.(CVE-2024-46673)In the Linux kernel, the following vulnerability has been resolved:usb: dwc3: st: fix probed platform device ref count on probe error pathThe probe function never performs any paltform device allocation, thuserror path &#34;undo_platform_dev_alloc&#34; is entirely bogus.  It drops thereference count from the platform device being probed.  If error path istriggered, this will lead to unbalanced device reference counts andpremature release of device resources, thus possible use-after-free whenreleasing remaining devm-managed resources.(CVE-2024-46674)In the Linux kernel, the following vulnerability has been resolved:ethtool: check device is present when getting link settingsA sysfs reader can race with a device reset or removal, attempting toread device state when the device is not actually present. eg:     [exception RIP: qed_get_current_link+17]  #8 [ffffb9e4f2907c48] qede_get_link_ksettings at ffffffffc07a994a [qede]  #9 [ffffb9e4f2907cd8] __rh_call_get_link_ksettings at ffffffff992b01a3 #10 [ffffb9e4f2907d38] __ethtool_get_link_ksettings at ffffffff992b04e4 #11 [ffffb9e4f2907d90] duplex_show at ffffffff99260300 #12 [ffffb9e4f2907e38] dev_attr_show at ffffffff9905a01c #13 [ffffb9e4f2907e50] sysfs_kf_seq_show at ffffffff98e0145b #14 [ffffb9e4f2907e68] seq_read at ffffffff98d902e3 #15 [ffffb9e4f2907ec8] vfs_read at ffffffff98d657d1 #16 [ffffb9e4f2907f00] ksys_read at ffffffff98d65c3f #17 [ffffb9e4f2907f38] do_syscall_64 at ffffffff98a052fb crash&gt; struct net_device.state ffff9a9d21336000    state = 5,state 5 is __LINK_STATE_START (0b1) and __LINK_STATE_NOCARRIER (0b100).The device is not present, note lack of __LINK_STATE_PRESENT (0b10).This is the same sort of panic as observed in commit 4224cfd7fb65(&#34;net-sysfs: add check for netdevice being present to speed_show&#34;).There are many other callers of __ethtool_get_link_ksettings() whichdon&#39;t have a device presence check.Move this check into ethtool to protect all callers.(CVE-2024-46679)In the Linux kernel, the following vulnerability has been resolved:pktgen: use cpus_read_lock() in pg_net_init()I have seen the WARN_ON(smp_processor_id() != cpu) firingin pktgen_thread_worker() during tests.We must use cpus_read_lock()/cpus_read_unlock()around the for_each_online_cpu(cpu) loop.While we are at it use WARN_ON_ONCE() to avoid a possible syslog flood.(CVE-2024-46681)In the Linux kernel, the following vulnerability has been resolved:selinux,smack: don&#39;t bypass permissions check in inode_setsecctx hookMarek Gresko reports that the root user on an NFS client is able tochange the security labels on files on an NFS filesystem that isexported with root squashing enabled.The end of the kerneldoc comment for __vfs_setxattr_noperm() states: *  This function requires the caller to lock the inode&#39;s i_mutex before it *  is executed. It also assumes that the caller will make the appropriate *  permission checks.nfsd_setattr() does do permissions checking via fh_verify() andnfsd_permission(), but those don&#39;t do all the same permissions checksthat are done by security_inode_setxattr() and its related LSM hooks do.Since nfsd_setattr() is the only consumer of security_inode_setsecctx(),simplest solution appears to be to replace the call to__vfs_setxattr_noperm() with a call to __vfs_setxattr_locked().  Thisfixes the above issue and has the added benefit of causing nfsd torecall conflicting delegations on a file when a client tries to changeits security label.(CVE-2024-46695)In the Linux kernel, the following vulnerability has been resolved:KVM: arm64: Make ICC_*SGI*_EL1 undef in the absence of a vGICv3On a system with a GICv3, if a guest hasn&#39;t been configured withGICv3 and that the host is not capable of GICv2 emulation,a write to any of the ICC_*SGI*_EL1 registers is trapped to EL2.We therefore try to emulate the SGI access, only to hit a NULLpointer as no private interrupt is allocated (no GIC, remember?).The obvious fix is to give the guest what it deserves, in theshape of a UNDEF exception.(CVE-2024-46707)In the Linux kernel, the following vulnerability has been resolved:apparmor: fix possible NULL pointer dereferenceprofile-&gt;parent-&gt;dents[AAFS_PROF_DIR] could be NULL only if its parent is madefrom __create_missing_ancestors(..) and &#39;ent-&gt;old&#39; is NULL inaa_replace_profiles(..).In that case, it must return an error code and the code, -ENOENT representsits state that the path of its parent is not existed yet.BUG: kernel NULL pointer dereference, address: 0000000000000030PGD 0 P4D 0PREEMPT SMP PTICPU: 4 PID: 3362 Comm: apparmor_parser Not tainted 6.8.0-24-generic #24Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.15.0-1 04/01/2014RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc &lt;4d&gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff82baac10R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000FS:  00007be9f22cf740(0000) GS:ffff88817bc00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000030 CR3: 0000000134b08000 CR4: 00000000000006f0Call Trace: &lt;TASK&gt; ? show_regs+0x6d/0x80 ? __die+0x24/0x80 ? page_fault_oops+0x99/0x1b0 ? kernelmode_fixup_or_oops+0xb2/0x140 ? __bad_area_nosemaphore+0x1a5/0x2c0 ? find_vma+0x34/0x60 ? bad_area_nosemaphore+0x16/0x30 ? do_user_addr_fault+0x2a2/0x6b0 ? exc_page_fault+0x83/0x1b0 ? asm_exc_page_fault+0x27/0x30 ? aafs_create.constprop.0+0x7f/0x130 ? aafs_create.constprop.0+0x51/0x130 __aafs_profile_mkdir+0x3d6/0x480 aa_replace_profiles+0x83f/0x1270 policy_update+0xe3/0x180 profile_load+0xbc/0x150 ? rw_verify_area+0x47/0x140 vfs_write+0x100/0x480 ? __x64_sys_openat+0x55/0xa0 ? syscall_exit_to_user_mode+0x86/0x260 ksys_write+0x73/0x100 __x64_sys_write+0x19/0x30 x64_sys_call+0x7e/0x25c0 do_syscall_64+0x7f/0x180 entry_SYSCALL_64_after_hwframe+0x78/0x80RIP: 0033:0x7be9f211c574Code: c7 00 16 00 00 00 b8 ff ff ff ff c3 66 2e 0f 1f 84 00 00 00 00 00 f3 0f 1e fa 80 3d d5 ea 0e 00 00 74 13 b8 01 00 00 00 0f 05 &lt;48&gt; 3d 00 f0 ff ff 77 54 c3 0f 1f 00 55 48 89 e5 48 83 ec 20 48 89RSP: 002b:00007ffd26f2b8c8 EFLAGS: 00000202 ORIG_RAX: 0000000000000001RAX: ffffffffffffffda RBX: 00005d504415e200 RCX: 00007be9f211c574RDX: 0000000000001fc1 RSI: 00005d504418bc80 RDI: 0000000000000004RBP: 0000000000001fc1 R08: 0000000000001fc1 R09: 0000000080000000R10: 0000000000000000 R11: 0000000000000202 R12: 00005d504418bc80R13: 0000000000000004 R14: 00007ffd26f2b9b0 R15: 00007ffd26f2ba30 &lt;/TASK&gt;Modules linked in: snd_seq_dummy snd_hrtimer qrtr snd_hda_codec_generic snd_hda_intel snd_intel_dspcfg snd_intel_sdw_acpi snd_hda_codec snd_hda_core snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi snd_seq snd_seq_device i2c_i801 snd_timer i2c_smbus qxl snd soundcore drm_ttm_helper lpc_ich ttm joydev input_leds serio_raw mac_hid binfmt_misc msr parport_pc ppdev lp parport efi_pstore nfnetlink dmi_sysfs qemu_fw_cfg ip_tables x_tables autofs4 hid_generic usbhid hid ahci libahci psmouse virtio_rng xhci_pci xhci_pci_renesasCR2: 0000000000000030---[ end trace 0000000000000000 ]---RIP: 0010:aafs_create.constprop.0+0x7f/0x130Code: 4c 63 e0 48 83 c4 18 4c 89 e0 5b 41 5c 41 5d 41 5e 41 5f 5d 31 d2 31 c9 31 f6 31 ff 45 31 c0 45 31 c9 45 31 d2 c3 cc cc cc cc &lt;4d&gt; 8b 55 30 4d 8d ba a0 00 00 00 4c 89 55 c0 4c 89 ff e8 7a 6a aeRSP: 0018:ffffc9000b2c7c98 EFLAGS: 00010246RAX: 0000000000000000 RBX: 00000000000041ed RCX: 0000000000000000RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000000RBP: ffffc9000b2c7cd8 R08: 0000000000000000 R09: 0000000000000000R10: 0000---truncated---(CVE-2024-46721)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: Fix out-of-bounds write warningCheck the ring type value to fix the out-of-boundswrite warning(CVE-2024-46725)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Ensure index calculation will not overflow[WHY &amp; HOW]Make sure vmid0p72_idx, vnom0p8_idx and vmax0p9_idx calculation willnever overflow and exceess array size.This fixes 3 OVERRUN and 1 INTEGER_OVERFLOW issues reported by Coverity.(CVE-2024-46726)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Assign linear_pitch_alignment even for VM[Description]Assign linear_pitch_alignment so we don&#39;t cause a divide by 0error in VM environments(CVE-2024-46732)In the Linux kernel, the following vulnerability has been resolved:nvmet-tcp: fix kernel crash if commands allocation failsIf the commands allocation fails in nvmet_tcp_alloc_cmds()the kernel crashes in nvmet_tcp_release_queue_work() because ofa NULL pointer dereference.  nvmet: failed to install queue 0 cntlid 1 ret 6  Unable to handle kernel NULL pointer dereference at         virtual address 0000000000000008Fix the bug by setting queue-&gt;nr_cmds to zero in casenvmet_tcp_alloc_cmd() fails.(CVE-2024-46737)In the Linux kernel, the following vulnerability has been resolved:VMCI: Fix use-after-free when removing resource in vmci_resource_remove()When removing a resource from vmci_resource_table invmci_resource_remove(), the search is performed using the resourcehandle by comparing context and resource fields.It is possible though to create two resources with different typesbut same handle (same context and resource fields).When trying to remove one of the resources, vmci_resource_remove()may not remove the intended one, but the object will still be freedas in the case of the datagram type in vmci_datagram_destroy_handle().vmci_resource_table will still hold a pointer to this freed resourceleading to a use-after-free vulnerability.BUG: KASAN: use-after-free in vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline]BUG: KASAN: use-after-free in vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147Read of size 4 at addr ffff88801c16d800 by task syz-executor197/1592Call Trace: &lt;TASK&gt; __dump_stack lib/dump_stack.c:88 [inline] dump_stack_lvl+0x82/0xa9 lib/dump_stack.c:106 print_address_description.constprop.0+0x21/0x366 mm/kasan/report.c:239 __kasan_report.cold+0x7f/0x132 mm/kasan/report.c:425 kasan_report+0x38/0x51 mm/kasan/report.c:442 vmci_handle_is_equal include/linux/vmw_vmci_defs.h:142 [inline] vmci_resource_remove+0x3a1/0x410 drivers/misc/vmw_vmci/vmci_resource.c:147 vmci_qp_broker_detach+0x89a/0x11b9 drivers/misc/vmw_vmci/vmci_queue_pair.c:2182 ctx_free_ctx+0x473/0xbe1 drivers/misc/vmw_vmci/vmci_context.c:444 kref_put include/linux/kref.h:65 [inline] vmci_ctx_put drivers/misc/vmw_vmci/vmci_context.c:497 [inline] vmci_ctx_destroy+0x170/0x1d6 drivers/misc/vmw_vmci/vmci_context.c:195 vmci_host_close+0x125/0x1ac drivers/misc/vmw_vmci/vmci_host.c:143 __fput+0x261/0xa34 fs/file_table.c:282 task_work_run+0xf0/0x194 kernel/task_work.c:164 tracehook_notify_resume include/linux/tracehook.h:189 [inline] exit_to_user_mode_loop+0x184/0x189 kernel/entry/common.c:187 exit_to_user_mode_prepare+0x11b/0x123 kernel/entry/common.c:220 __syscall_exit_to_user_mode_work kernel/entry/common.c:302 [inline] syscall_exit_to_user_mode+0x18/0x42 kernel/entry/common.c:313 do_syscall_64+0x41/0x85 arch/x86/entry/common.c:86 entry_SYSCALL_64_after_hwframe+0x6e/0x0This change ensures the type is also checked when removingthe resource from vmci_resource_table in vmci_resource_remove().(CVE-2024-46738)In the Linux kernel, the following vulnerability has been resolved:uio_hv_generic: Fix kernel NULL pointer dereference in hv_uio_rescindFor primary VM Bus channels, primary_channel pointer is always NULL. Thispointer is valid only for the secondary channels. Also, rescind callbackis meant for primary channels only.Fix NULL pointer dereference by retrieving the device_obj from the parentfor the primary channel.(CVE-2024-46739)In the Linux kernel, the following vulnerability has been resolved:binder: fix UAF caused by offsets overwriteBinder objects are processed and copied individually into the targetbuffer during transactions. Any raw data in-between these objects iscopied as well. However, this raw data copy lacks an out-of-boundscheck. If the raw data exceeds the data section size then the copyoverwrites the offsets section. This eventually triggers an error thatattempts to unwind the processed objects. However, at this point theoffsets used to index these objects are now corrupted.Unwinding with corrupted offsets can result in decrements of arbitrarynodes and lead to their premature release. Other users of such nodes areleft with a dangling pointer triggering a use-after-free. This issue ismade evident by the following KASAN report (trimmed):  ==================================================================  BUG: KASAN: slab-use-after-free in _raw_spin_lock+0xe4/0x19c  Write of size 4 at addr ffff47fc91598f04 by task binder-util/743  CPU: 9 UID: 0 PID: 743 Comm: binder-util Not tainted 6.11.0-rc4 #1  Hardware name: linux,dummy-virt (DT)  Call trace:   _raw_spin_lock+0xe4/0x19c   binder_free_buf+0x128/0x434   binder_thread_write+0x8a4/0x3260   binder_ioctl+0x18f0/0x258c  [...]  Allocated by task 743:   __kmalloc_cache_noprof+0x110/0x270   binder_new_node+0x50/0x700   binder_transaction+0x413c/0x6da8   binder_thread_write+0x978/0x3260   binder_ioctl+0x18f0/0x258c  [...]  Freed by task 745:   kfree+0xbc/0x208   binder_thread_read+0x1c5c/0x37d4   binder_ioctl+0x16d8/0x258c  [...]  ==================================================================To avoid this issue, let&#39;s check that the raw data copy is within theboundaries of the data section.(CVE-2024-46740)In the Linux kernel, the following vulnerability has been resolved:smb/server: fix potential null-ptr-deref of lease_ctx_info in smb2_open()null-ptr-deref will occur when (req_op_level == SMB2_OPLOCK_LEVEL_LEASE)and parse_lease_state() return NULL.Fix this by check if &#39;lease_ctx_info&#39; is NULL.Additionally, remove the redundant parentheses inparse_durable_handle_context().(CVE-2024-46742)In the Linux kernel, the following vulnerability has been resolved:of/irq: Prevent device address out-of-bounds read in interrupt map walkWhen of_irq_parse_raw() is invoked with a device address smaller thanthe interrupt parent node (from #address-cells property), KASAN detectsthe following out-of-bounds read when populating the initial match table(dyndbg=&#34;func of_irq_parse_* +p&#34;):  OF: of_irq_parse_one: dev=/soc@0/picasso/watchdog, index=0  OF:  parent=/soc@0/pci@878000000000/gpio0@17,0, intsize=2  OF:  intspec=4  OF: of_irq_parse_raw: ipar=/soc@0/pci@878000000000/gpio0@17,0, size=2  OF:  -&gt; addrsize=3  ==================================================================  BUG: KASAN: slab-out-of-bounds in of_irq_parse_raw+0x2b8/0x8d0  Read of size 4 at addr ffffff81beca5608 by task bash/764  CPU: 1 PID: 764 Comm: bash Tainted: G           O       6.1.67-484c613561-nokia_sm_arm64 #1  Hardware name: Unknown Unknown Product/Unknown Product, BIOS 2023.01-12.24.03-dirty 01/01/2023  Call trace:   dump_backtrace+0xdc/0x130   show_stack+0x1c/0x30   dump_stack_lvl+0x6c/0x84   print_report+0x150/0x448   kasan_report+0x98/0x140   __asan_load4+0x78/0xa0   of_irq_parse_raw+0x2b8/0x8d0   of_irq_parse_one+0x24c/0x270   parse_interrupts+0xc0/0x120   of_fwnode_add_links+0x100/0x2d0   fw_devlink_parse_fwtree+0x64/0xc0   device_add+0xb38/0xc30   of_device_add+0x64/0x90   of_platform_device_create_pdata+0xd0/0x170   of_platform_bus_create+0x244/0x600   of_platform_notify+0x1b0/0x254   blocking_notifier_call_chain+0x9c/0xd0   __of_changeset_entry_notify+0x1b8/0x230   __of_changeset_apply_notify+0x54/0xe4   of_overlay_fdt_apply+0xc04/0xd94   ...  The buggy address belongs to the object at ffffff81beca5600   which belongs to the cache kmalloc-128 of size 128  The buggy address is located 8 bytes inside of   128-byte region [ffffff81beca5600, ffffff81beca5680)  The buggy address belongs to the physical page:  page:00000000230d3d03 refcount:1 mapcount:0 mapping:0000000000000000 index:0x0 pfn:0x1beca4  head:00000000230d3d03 order:1 compound_mapcount:0 compound_pincount:0  flags: 0x8000000000010200(slab|head|zone=2)  raw: 8000000000010200 0000000000000000 dead000000000122 ffffff810000c300  raw: 0000000000000000 0000000000200020 00000001ffffffff 0000000000000000  page dumped because: kasan: bad access detected  Memory state around the buggy address:   ffffff81beca5500: 04 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc   ffffff81beca5580: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc  &gt;ffffff81beca5600: 00 fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc                        ^   ffffff81beca5680: fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc fc   ffffff81beca5700: 00 00 00 00 00 00 fc fc fc fc fc fc fc fc fc fc  ==================================================================  OF:  -&gt; got it !Prevent the out-of-bounds read by copying the device address into abuffer of sufficient size.(CVE-2024-46743)In the Linux kernel, the following vulnerability has been resolved:PCI: Add missing bridge lock to pci_bus_lock()One of the true positives that the cfg_access_lock lockdep effortidentified is this sequence:  WARNING: CPU: 14 PID: 1 at drivers/pci/pci.c:4886 pci_bridge_secondary_bus_reset+0x5d/0x70  RIP: 0010:pci_bridge_secondary_bus_reset+0x5d/0x70  Call Trace:   &lt;TASK&gt;   ? __warn+0x8c/0x190   ? pci_bridge_secondary_bus_reset+0x5d/0x70   ? report_bug+0x1f8/0x200   ? handle_bug+0x3c/0x70   ? exc_invalid_op+0x18/0x70   ? asm_exc_invalid_op+0x1a/0x20   ? pci_bridge_secondary_bus_reset+0x5d/0x70   pci_reset_bus+0x1d8/0x270   vmd_probe+0x778/0xa10   pci_device_probe+0x95/0x120Where pci_reset_bus() users are triggering unlocked secondary bus resets.Ironically pci_bus_reset(), several calls down from pci_reset_bus(), usespci_bus_lock() before issuing the reset which locks everything *but* thebridge itself.For the same motivation as adding:  bridge = pci_upstream_bridge(dev);  if (bridge)    pci_dev_lock(bridge);to pci_reset_function() for the &#34;bus&#34; and &#34;cxl_bus&#34; reset cases, addpci_dev_lock() for @bus-&gt;self to pci_bus_lock().[bhelgaas: squash in recursive locking deadlock fix from Keith Busch:https://lore.kernel.org/r/20240711193650.701834-1-kbusch@meta.com](CVE-2024-46750)In the Linux kernel, the following vulnerability has been resolved:btrfs: handle errors from btrfs_dec_ref() properlyIn walk_up_proc() we BUG_ON(ret) from btrfs_dec_ref().  This isincorrect, we have proper error handling here, return the error.(CVE-2024-46753)In the Linux kernel, the following vulnerability has been resolved:wifi: mwifiex: Do not return unused priv in mwifiex_get_priv_by_id()mwifiex_get_priv_by_id() returns the priv pointer corresponding tothe bss_num and bss_type, but without checking if the priv is actuallycurrently in use.Unused priv pointers do not have a wiphy attached to them which canlead to NULL pointer dereferences further down the callstack.  Fixthis by returning only used priv pointers which have priv-&gt;bss_modeset to something else than NL80211_IFTYPE_UNSPECIFIED.Said NULL pointer dereference happened when an Accesspoint was startedwith wpa_supplicant -i mlan0 with this config:network={        ssid=&#34;somessid&#34;        mode=2        frequency=2412        key_mgmt=WPA-PSK WPA-PSK-SHA256        proto=RSN        group=CCMP        pairwise=CCMP        psk=&#34;12345678&#34;}When waiting for the AP to be established, interrupting wpa_supplicantwith &lt;ctrl-c&gt; and starting it again this happens:| Unable to handle kernel NULL pointer dereference at virtual address 0000000000000140| 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=0000000046d96000| [0000000000000140] pgd=0000000000000000, p4d=0000000000000000| Internal error: Oops: 0000000096000004 [#1] PREEMPT SMP| Modules linked in: caam_jr caamhash_desc spidev caamalg_desc crypto_engine authenc libdes mwifiex_sdio+mwifiex crct10dif_ce cdc_acm onboard_usb_hub fsl_imx8_ddr_perf imx8m_ddrc rtc_ds1307 lm75 rtc_snvs+imx_sdma caam imx8mm_thermal spi_imx error imx_cpufreq_dt fuse ip_tables x_tables ipv6| CPU: 0 PID: 8 Comm: kworker/0:1 Not tainted 6.9.0-00007-g937242013fce-dirty #18| Hardware name: somemachine (DT)| Workqueue: events sdio_irq_work| pstate: 00000005 (nzcv daif -PAN -UAO -TCO -DIT -SSBS BTYPE=--)| pc : mwifiex_get_cfp+0xd8/0x15c [mwifiex]| lr : mwifiex_get_cfp+0x34/0x15c [mwifiex]| sp : ffff8000818b3a70| x29: ffff8000818b3a70 x28: ffff000006bfd8a5 x27: 0000000000000004| x26: 000000000000002c x25: 0000000000001511 x24: 0000000002e86bc9| x23: ffff000006bfd996 x22: 0000000000000004 x21: ffff000007bec000| x20: 000000000000002c x19: 0000000000000000 x18: 0000000000000000| x17: 000000040044ffff x16: 00500072b5503510 x15: ccc283740681e517| x14: 0201000101006d15 x13: 0000000002e8ff43 x12: 002c01000000ffb1| x11: 0100000000000000 x10: 02e8ff43002c0100 x9 : 0000ffb100100157| x8 : ffff000003d20000 x7 : 00000000000002f1 x6 : 00000000ffffe124| x5 : 0000000000000001 x4 : 0000000000000003 x3 : 0000000000000000| x2 : 0000000000000000 x1 : 0001000000011001 x0 : 0000000000000000| Call trace:|  mwifiex_get_cfp+0xd8/0x15c [mwifiex]|  mwifiex_parse_single_response_buf+0x1d0/0x504 [mwifiex]|  mwifiex_handle_event_ext_scan_report+0x19c/0x2f8 [mwifiex]|  mwifiex_process_sta_event+0x298/0xf0c [mwifiex]|  mwifiex_process_event+0x110/0x238 [mwifiex]|  mwifiex_main_process+0x428/0xa44 [mwifiex]|  mwifiex_sdio_interrupt+0x64/0x12c [mwifiex_sdio]|  process_sdio_pending_irqs+0x64/0x1b8|  sdio_irq_work+0x4c/0x7c|  process_one_work+0x148/0x2a0|  worker_thread+0x2fc/0x40c|  kthread+0x110/0x114|  ret_from_fork+0x10/0x20| Code: a94153f3 a8c37bfd d50323bf d65f03c0 (f940a000)| ---[ end trace 0000000000000000 ]---(CVE-2024-46755)In the Linux kernel, the following vulnerability has been resolved:hwmon: (w83627ehf) Fix underflows seen when writing limit attributesDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a largenegative number such as -9223372036854775808 is provided by the user.Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46756)In the Linux kernel, the following vulnerability has been resolved:hwmon: (lm95234) Fix underflows seen when writing limit attributesDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a largenegative number such as -9223372036854775808 is provided by the user.Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46758)In the Linux kernel, the following vulnerability has been resolved:hwmon: (adc128d818) Fix underflows seen when writing limit attributesDIV_ROUND_CLOSEST() after kstrtol() results in an underflow if a largenegative number such as -9223372036854775808 is provided by the user.Fix it by reordering clamp_val() and DIV_ROUND_CLOSEST() operations.(CVE-2024-46759)In the Linux kernel, the following vulnerability has been resolved:pci/hotplug/pnv_php: Fix hotplug driver crash on PowernvThe hotplug driver for powerpc (pci/hotplug/pnv_php.c) causes a kernelcrash when we try to hot-unplug/disable the PCIe switch/bridge fromthe PHB.The crash occurs because although the MSI data structure has beenreleased during disable/hot-unplug path and it has been assignedwith NULL, still during unregistration the code was again trying toexplicitly disable the MSI which causes the NULL pointer dereference andkernel crash.The patch fixes the check during unregistration path to prevent invokingpci_disable_msi/msix() since its data structure is already freed.(CVE-2024-46761)In the Linux kernel, the following vulnerability has been resolved:can: bcm: Remove proc entry when dev is unregistered.syzkaller reported a warning in bcm_connect() below. [0]The repro calls connect() to vxcan1, removes vxcan1, and callsconnect() with ifindex == 0.Calling connect() for a BCM socket allocates a proc entry.Then, bcm_sk(sk)-&gt;bound is set to 1 to prevent further connect().However, removing the bound device resets bcm_sk(sk)-&gt;bound to 0in bcm_notify().The 2nd connect() tries to allocate a proc entry with the samename and sets NULL to bcm_sk(sk)-&gt;bcm_proc_read, leaking theoriginal proc entry.Since the proc entry is available only for connect()ed sockets,let&#39;s clean up the entry when the bound netdev is unregistered.[0]:proc_dir_entry &#39;can-bcm/2456&#39; already registeredWARNING: CPU: 1 PID: 394 at fs/proc/generic.c:376 proc_register+0x645/0x8f0 fs/proc/generic.c:375Modules linked in:CPU: 1 PID: 394 Comm: syz-executor403 Not tainted 6.10.0-rc7-g852e42cc2dd4Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.16.3-0-ga6ed6b701f0a-prebuilt.qemu.org 04/01/2014RIP: 0010:proc_register+0x645/0x8f0 fs/proc/generic.c:375Code: 00 00 00 00 00 48 85 ed 0f 85 97 02 00 00 4d 85 f6 0f 85 9f 02 00 00 48 c7 c7 9b cb cf 87 48 89 de 4c 89 fa e8 1c 6f eb fe 90 &lt;0f&gt; 0b 90 90 48 c7 c7 98 37 99 89 e8 cb 7e 22 05 bb 00 00 00 10 48RSP: 0018:ffa0000000cd7c30 EFLAGS: 00010246RAX: 9e129be1950f0200 RBX: ff1100011b51582c RCX: ff1100011857cd80RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000000000002RBP: 0000000000000000 R08: ffd400000000000f R09: ff1100013e78cac0R10: ffac800000cd7980 R11: ff1100013e12b1f0 R12: 0000000000000000R13: 0000000000000000 R14: 0000000000000000 R15: ff1100011a99a2ecFS:  00007fbd7086f740(0000) GS:ff1100013fd00000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 00000000200071c0 CR3: 0000000118556004 CR4: 0000000000771ef0DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000DR3: 0000000000000000 DR6: 00000000fffe07f0 DR7: 0000000000000400PKRU: 55555554Call Trace: &lt;TASK&gt; proc_create_net_single+0x144/0x210 fs/proc/proc_net.c:220 bcm_connect+0x472/0x840 net/can/bcm.c:1673 __sys_connect_file net/socket.c:2049 [inline] __sys_connect+0x5d2/0x690 net/socket.c:2066 __do_sys_connect net/socket.c:2076 [inline] __se_sys_connect net/socket.c:2073 [inline] __x64_sys_connect+0x8f/0x100 net/socket.c:2073 do_syscall_x64 arch/x86/entry/common.c:52 [inline] do_syscall_64+0xd9/0x1c0 arch/x86/entry/common.c:83 entry_SYSCALL_64_after_hwframe+0x4b/0x53RIP: 0033:0x7fbd708b0e5dCode: 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 48RSP: 002b:00007fff8cd33f08 EFLAGS: 00000246 ORIG_RAX: 000000000000002aRAX: ffffffffffffffda RBX: 0000000000000003 RCX: 00007fbd708b0e5dRDX: 0000000000000010 RSI: 0000000020000040 RDI: 0000000000000003RBP: 0000000000000000 R08: 0000000000000040 R09: 0000000000000040R10: 0000000000000040 R11: 0000000000000246 R12: 00007fff8cd34098R13: 0000000000401280 R14: 0000000000406de8 R15: 00007fbd70ab9000 &lt;/TASK&gt;remove_proc_entry: removing non-empty directory &#39;net/can-bcm&#39;, leaking at least &#39;2456&#39;(CVE-2024-46771)In the Linux kernel, the following vulnerability has been resolved:udf: Avoid excessive partition lengthsAvoid mounting filesystems where the partition would overflow the32-bits used for block number. Also refuse to mount filesystems wherethe partition length is so large we cannot safely index bits in ablock bitmap.(CVE-2024-46777)In the Linux kernel, the following vulnerability has been resolved:nilfs2: protect references to superblock parameters exposed in sysfsThe superblock buffers of nilfs2 can not only be overwritten at runtimefor modifications/repairs, but they are also regularly swapped, replacedduring resizing, and even abandoned when degrading to one side due tobacking device issues.  So, accessing them requires mutual exclusion usingthe reader/writer semaphore &#34;nilfs-&gt;ns_sem&#34;.Some sysfs attribute show methods read this superblock buffer without thenecessary mutual exclusion, which can cause problems with pointerdereferencing and memory access, so fix it.(CVE-2024-46780)In the Linux kernel, the following vulnerability has been resolved:nilfs2: fix missing cleanup on rollforward recovery errorIn an error injection test of a routine for mount-time recovery, KASANfound a use-after-free bug.It turned out that if data recovery was performed using partial logscreated by dsync writes, but an error occurred before starting the logwriter to create a recovered checkpoint, the inodes whose data had beenrecovered were left in the ns_dirty_files list of the nilfs object andwere not freed.Fix this issue by cleaning up inodes that have read the recovery data ifthe recovery routine fails midway before the log writer starts.(CVE-2024-46781)In the Linux kernel, the following vulnerability has been resolved:can: mcp251x: fix deadlock if an interrupt occurs during mcp251x_openThe mcp251x_hw_wake() function is called with the mpc_lock mutex held anddisables the interrupt handler so that no interrupts can be processed whilewaking the device. If an interrupt has already occurred then waiting forthe interrupt handler to complete will deadlock because it will be tryingto acquire the same mutex.CPU0                           CPU1----                           ----mcp251x_open() mutex_lock(&amp;priv-&gt;mcp_lock)  request_threaded_irq()                               &lt;interrupt&gt;                               mcp251x_can_ist()                                mutex_lock(&amp;priv-&gt;mcp_lock)  mcp251x_hw_wake()   disable_irq() &lt;-- deadlockUse disable_irq_nosync() instead because the interrupt handler doeseverything while holding the mutex so it doesn&#39;t matter if it&#39;s stillrunning.(CVE-2024-46791)In the Linux kernel, the following vulnerability has been resolved:ASoC: dapm: Fix UAF for snd_soc_pcm_runtime objectWhen using kernel with the following extra config,  - CONFIG_KASAN=y  - CONFIG_KASAN_GENERIC=y  - CONFIG_KASAN_INLINE=y  - CONFIG_KASAN_VMALLOC=y  - CONFIG_FRAME_WARN=4096kernel detects that snd_pcm_suspend_all() access a freed&#39;snd_soc_pcm_runtime&#39; object when the system is suspended, whichleads to a use-after-free bug:[   52.047746] BUG: KASAN: use-after-free in snd_pcm_suspend_all+0x1a8/0x270[   52.047765] Read of size 1 at addr ffff0000b9434d50 by task systemd-sleep/2330[   52.047785] Call trace:[   52.047787]  dump_backtrace+0x0/0x3c0[   52.047794]  show_stack+0x34/0x50[   52.047797]  dump_stack_lvl+0x68/0x8c[   52.047802]  print_address_description.constprop.0+0x74/0x2c0[   52.047809]  kasan_report+0x210/0x230[   52.047815]  __asan_report_load1_noabort+0x3c/0x50[   52.047820]  snd_pcm_suspend_all+0x1a8/0x270[   52.047824]  snd_soc_suspend+0x19c/0x4e0The snd_pcm_sync_stop() has a NULL check on &#39;substream-&gt;runtime&#39; beforemaking any access. So we need to always set &#39;substream-&gt;runtime&#39; to NULLeverytime we kfree() it.(CVE-2024-46798)In the Linux kernel, the following vulnerability has been resolved:sch/netem: fix use after free in netem_dequeueIf netem_dequeue() enqueues packet to inner qdisc and that qdiscreturns __NET_XMIT_STOLEN. The packet is dropped butqdisc_tree_reduce_backlog() is not called to update the parent&#39;sq.qlen, leading to the similar use-after-free as Commite04991a48dbaf382 (&#34;netem: fix return value if duplicate enqueuefails&#34;)Commands to trigger KASAN UaF:ip link add type dummyip link set lo upip link set dummy0 uptc qdisc add dev lo parent root handle 1: drrtc filter add dev lo parent 1: basic classid 1:1tc class add dev lo classid 1:1 drrtc qdisc add dev lo parent 1:1 handle 2: netemtc qdisc add dev lo parent 2: handle 3: drrtc filter add dev lo parent 3: basic classid 3:1 action mirred egressredirect dev dummy0tc class add dev lo classid 3:1 drrping -c1 -W0.01 localhost # Trigger bugtc class del dev lo classid 1:1tc class add dev lo classid 1:1 drrping -c1 -W0.01 localhost # UaF(CVE-2024-46800)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Add array index check for hdcp ddc access[Why]Coverity reports OVERRUN warning. Do not check if arrayindex valid.[How]Check msg_id valid and valid array index.(CVE-2024-46804)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check msg_id before processing transcation[WHY &amp; HOW]HDCP_MESSAGE_ID_INVALID (-1) is not a valid msg_id nor is it a validarray index, and it needs checking before used.This fixes 4 OVERRUN issues reported by Coverity.(CVE-2024-46814)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Stop amdgpu_dm initialize when link nums greater than max_links[Why]Coverity report OVERRUN warning. There areonly max_links elements within dc-&gt;links. linkcount could up to AMDGPU_DM_MAX_DISPLAY_INDEX 31.[How]Make sure link count less than max_links.(CVE-2024-46816)In the Linux kernel, the following vulnerability has been resolved:drm/amd/display: Check gpio_id before used as array index[WHY &amp; HOW]GPIO_ID_UNKNOWN (-1) is not a valid value for array index and thereforeshould be checked in advance.This fixes 5 OVERRUN issues reported by Coverity.(CVE-2024-46818)In the Linux kernel, the following vulnerability has been resolved:drm/amd/pm: Fix negative array index readAvoid using the negative valuesfor clk_idex as an index into an array pptable-&gt;DpmDescriptor.V2: fix clk_index return check (Tim Huang)(CVE-2024-46821)In the Linux kernel, the following vulnerability has been resolved:rtmutex: Drop rt_mutex::wait_lock before schedulingrt_mutex_handle_deadlock() is called with rt_mutex::wait_lock held.  In thegood case it returns with the lock held and in the deadlock case it emits awarning and goes into an endless scheduling loop with the lock held, whichtriggers the &#39;scheduling in atomic&#39; warning.Unlock rt_mutex::wait_lock in the dead lock case before issuing the warningand dropping into the schedule for ever loop.[ tglx: Moved unlock before the WARN(), removed the pointless comment,  &#x9;massaged changelog, added Fixes tag ](CVE-2024-46829)In the Linux kernel, the following vulnerability has been resolved:btrfs: don&#39;t BUG_ON on ENOMEM from btrfs_lookup_extent_info() in walk_down_proc()We handle errors here properly, ENOMEM isn&#39;t fatal, return the error.(CVE-2024-46841)In the Linux kernel, the following vulnerability has been resolved:um: line: always fill *error_out in setup_one_line()The pointer isn&#39;t initialized by callers, but I haveencountered cases where it&#39;s still printed; initializeit in all possible cases in setup_one_line().(CVE-2024-46844)In the Linux kernel, the following vulnerability has been resolved:ASoC: meson: axg-card: fix &#39;use-after-free&#39;Buffer &#39;card-&gt;dai_link&#39; is reallocated in &#39;meson_card_reallocate_links()&#39;,so move &#39;pad&#39; pointer initialization after this function when memory isalready reallocated.Kasan bug report:==================================================================BUG: KASAN: slab-use-after-free in axg_card_add_link+0x76c/0x9bcRead of size 8 at addr ffff000000e8b260 by task modprobe/356CPU: 0 PID: 356 Comm: modprobe Tainted: G O 6.9.12-sdkernel #1Call trace: dump_backtrace+0x94/0xec show_stack+0x18/0x24 dump_stack_lvl+0x78/0x90 print_report+0xfc/0x5c0 kasan_report+0xb8/0xfc __asan_load8+0x9c/0xb8 axg_card_add_link+0x76c/0x9bc [snd_soc_meson_axg_sound_card] meson_card_probe+0x344/0x3b8 [snd_soc_meson_card_utils] platform_probe+0x8c/0xf4 really_probe+0x110/0x39c __driver_probe_device+0xb8/0x18c driver_probe_device+0x108/0x1d8 __driver_attach+0xd0/0x25c bus_for_each_dev+0xe0/0x154 driver_attach+0x34/0x44 bus_add_driver+0x134/0x294 driver_register+0xa8/0x1e8 __platform_driver_register+0x44/0x54 axg_card_pdrv_init+0x20/0x1000 [snd_soc_meson_axg_sound_card] do_one_initcall+0xdc/0x25c do_init_module+0x10c/0x334 load_module+0x24c4/0x26cc init_module_from_file+0xd4/0x128 __arm64_sys_finit_module+0x1f4/0x41c invoke_syscall+0x60/0x188 el0_svc_common.constprop.0+0x78/0x13c do_el0_svc+0x30/0x40 el0_svc+0x38/0x78 el0t_64_sync_handler+0x100/0x12c el0t_64_sync+0x190/0x194(CVE-2024-46849)In the Linux kernel, the following vulnerability has been resolved:net/mlx5: Fix bridge mode operations when there are no VFsCurrently, trying to set the bridge mode attribute when numvfs=0 leads to acrash:bridge link set dev eth2 hwmode vepa[  168.967392] BUG: kernel NULL pointer dereference, address: 0000000000000030[...][  168.969989] RIP: 0010:mlx5_add_flow_rules+0x1f/0x300 [mlx5_core][...][  168.976037] Call Trace:[  168.976188]  &lt;TASK&gt;[  168.978620]  _mlx5_eswitch_set_vepa_locked+0x113/0x230 [mlx5_core][  168.979074]  mlx5_eswitch_set_vepa+0x7f/0xa0 [mlx5_core][  168.979471]  rtnl_bridge_setlink+0xe9/0x1f0[  168.979714]  rtnetlink_rcv_msg+0x159/0x400[  168.980451]  netlink_rcv_skb+0x54/0x100[  168.980675]  netlink_unicast+0x241/0x360[  168.980918]  netlink_sendmsg+0x1f6/0x430[  168.981162]  ____sys_sendmsg+0x3bb/0x3f0[  168.982155]  ___sys_sendmsg+0x88/0xd0[  168.985036]  __sys_sendmsg+0x59/0xa0[  168.985477]  do_syscall_64+0x79/0x150[  168.987273]  entry_SYSCALL_64_after_hwframe+0x76/0x7e[  168.987773] RIP: 0033:0x7f8f7950f917(esw-&gt;fdb_table.legacy.vepa_fdb is null)The bridge mode is only relevant when there are multiple functions perport. Therefore, prevent setting and getting this setting when there are noVFs.Note that after this change, there are no settings to change on the PFinterface using `bridge link` when there are no VFs, so the interface nolonger appears in the `bridge link` output.(CVE-2024-46857)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.96.0.177.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.96.0.177.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2221</id>
          <title>An update for libgsf is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36474" id="CVE-2024-36474" title="CVE-2024-36474" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42415" id="CVE-2024-42415" title="CVE-2024-42415" type="cve"></reference>
          </references>
          <description>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-36474)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.(CVE-2024-42415)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libgsf" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-1.14.47-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsf-debuginfo" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-debuginfo-1.14.47-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsf-debugsource" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-debugsource-1.14.47-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsf-devel" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-devel-1.14.47-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libgsf-help" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-help-1.14.47-2.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-1.14.47-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf-debuginfo" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-debuginfo-1.14.47-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf-debugsource" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-debugsource-1.14.47-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf-devel" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-devel-1.14.47-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libgsf-help" release="2.oe2203sp1" version="1.14.47">
                         <filename>libgsf-help-1.14.47-2.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2223</id>
          <title>An update for cups is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47175" id="CVE-2024-47175" title="CVE-2024-47175" type="cve"></reference>
          </references>
          <description>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-47175)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="cups" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-client" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debuginfo" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-debugsource" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-devel" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-ipptool" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-libs" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-lpd" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="cups-printerapp" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-13.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-filesystem" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-filesystem-2.4.0-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="noarch" name="cups-help" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-help-2.4.0-13.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-client" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-client-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debuginfo" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-debuginfo-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-debugsource" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-debugsource-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-devel" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-devel-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-ipptool" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-ipptool-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-libs" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-libs-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-lpd" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-lpd-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="cups-printerapp" release="13.oe2203sp1" version="2.4.0">
                         <filename>cups-printerapp-2.4.0-13.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2226</id>
          <title>An update for rubygem-webrick is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47220" id="CVE-2024-47220" title="CVE-2024-47220" type="cve"></reference>
          </references>
          <description>An issue was discovered in the WEBrick toolkit through 1.8.1 for Ruby. It allows HTTP request smuggling by providing both a Content-Length header and a Transfer-Encoding header, e.g., &#34;GET /admin HTTP/1.1\r\n&#34; inside of a &#34;POST /user HTTP/1.1\r\n&#34; request. NOTE: the supplier&#39;s position is &#34;Webrick should not be used in production.&#34;(CVE-2024-47220)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="rubygem-webrick" release="2.oe2203sp1" version="1.7.0">
                         <filename>rubygem-webrick-1.7.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-webrick-help" release="2.oe2203sp1" version="1.7.0">
                         <filename>rubygem-webrick-help-1.7.0-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2227</id>
          <title>An update for avro is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47561" id="CVE-2024-47561" title="CVE-2024-47561" type="cve"></reference>
          </references>
          <description>Schema parsing in the Java SDK of Apache Avro 1.11.3 and previous versions allows bad actors to execute arbitrary code.Users are recommended to upgrade to version 1.11.4  or 1.12.0, which fix this issue.(CVE-2024-47561)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="avro" release="6.oe2203sp1" version="1.10.2">
                         <filename>avro-1.10.2-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="avro" release="6.oe2203sp1" version="1.10.2">
                         <filename>avro-1.10.2-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2228</id>
          <title>An update for json-lib is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47855" id="CVE-2024-47855" title="CVE-2024-47855" type="cve"></reference>
          </references>
          <description>util/JSONTokener.java in JSON-lib before 3.1.0 mishandles an unbalanced comment string.(CVE-2024-47855)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="jenkins-json-lib" release="23.oe2203sp1" version="2.4">
                         <filename>jenkins-json-lib-2.4-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="json-lib" release="23.oe2203sp1" version="2.4">
                         <filename>json-lib-2.4-23.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="json-lib-help" release="23.oe2203sp1" version="2.4">
                         <filename>json-lib-help-2.4-23.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2234</id>
          <title>An update for unbound is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-33655" id="CVE-2024-33655" title="CVE-2024-33655" type="cve"></reference>
          </references>
          <description>The DNS protocol in RFC 1035 and updates allows remote attackers to cause a denial of service (resource consumption) by arranging for DNS queries to be accumulated for seconds, such that responses are later sent in a pulsing burst (which can be considered traffic amplification in some cases), aka the &#34;DNSBomb&#34; issue.(CVE-2024-33655)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-unbound" release="14.oe2203sp1" version="1.13.2">
                         <filename>python3-unbound-1.13.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-1.13.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debuginfo" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debugsource" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-devel" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-devel-1.13.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-help" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-help-1.13.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-libs" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-libs-1.13.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unbound" release="14.oe2203sp1" version="1.13.2">
                         <filename>python3-unbound-1.13.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-1.13.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debuginfo" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debugsource" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-devel" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-devel-1.13.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-help" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-help-1.13.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-libs" release="14.oe2203sp1" version="1.13.2">
                         <filename>unbound-libs-1.13.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2235</id>
          <title>An update for vim is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47814" id="CVE-2024-47814" title="CVE-2024-47814" type="cve"></reference>
          </references>
          <description>Vim is an open source, command line text editor. A use-after-free was found in Vim &lt; 9.1.0764. When closing a buffer (visible in a window) a BufWinLeave auto command can cause an use-after-free if this auto command happens to re-open the same buffer in a new split window. Impact is low since the user must have intentionally set up such a strange auto command and run some buffer unload commands. However this may lead to a crash. This issue has been addressed in version 9.1.0764 and all users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2024-47814)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="2" arch="aarch64" name="vim-X11" release="28.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-common" release="28.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debuginfo" release="28.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-debugsource" release="28.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-enhanced" release="28.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="aarch64" name="vim-minimal" release="28.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-28.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="2" arch="noarch" name="vim-filesystem" release="28.oe2203sp1" version="9.0">
                         <filename>vim-filesystem-9.0-28.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-X11" release="28.oe2203sp1" version="9.0">
                         <filename>vim-X11-9.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-common" release="28.oe2203sp1" version="9.0">
                         <filename>vim-common-9.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debuginfo" release="28.oe2203sp1" version="9.0">
                         <filename>vim-debuginfo-9.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-debugsource" release="28.oe2203sp1" version="9.0">
                         <filename>vim-debugsource-9.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-enhanced" release="28.oe2203sp1" version="9.0">
                         <filename>vim-enhanced-9.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="2" arch="x86_64" name="vim-minimal" release="28.oe2203sp1" version="9.0">
                         <filename>vim-minimal-9.0-28.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2237</id>
          <title>An update for xterm is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-45063" id="CVE-2022-45063" title="CVE-2022-45063" type="cve"></reference>
          </references>
          <description>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.(CVE-2022-45063)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xterm" release="6.oe2203sp1" version="363">
                         <filename>xterm-363-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xterm-debuginfo" release="6.oe2203sp1" version="363">
                         <filename>xterm-debuginfo-363-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xterm-debugsource" release="6.oe2203sp1" version="363">
                         <filename>xterm-debugsource-363-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xterm-help" release="6.oe2203sp1" version="363">
                         <filename>xterm-help-363-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xterm" release="6.oe2203sp1" version="363">
                         <filename>xterm-363-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xterm-debuginfo" release="6.oe2203sp1" version="363">
                         <filename>xterm-debuginfo-363-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xterm-debugsource" release="6.oe2203sp1" version="363">
                         <filename>xterm-debugsource-363-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xterm-help" release="6.oe2203sp1" version="363">
                         <filename>xterm-help-363-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2242</id>
          <title>An update for wireshark is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-24476" id="CVE-2024-24476" title="CVE-2024-24476" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8645" id="CVE-2024-8645" title="CVE-2024-8645" type="cve"></reference>
          </references>
          <description>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-24476)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-8645)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package epoch="1" arch="aarch64" name="wireshark" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debuginfo" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-debugsource" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-devel" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="aarch64" name="wireshark-help" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-3.6.14-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debuginfo" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debuginfo-3.6.14-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-debugsource" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-debugsource-3.6.14-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-devel" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-devel-3.6.14-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package epoch="1" arch="x86_64" name="wireshark-help" release="11.oe2203sp1" version="3.6.14">
                         <filename>wireshark-help-3.6.14-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2243</id>
          <title>An update for fop is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28168" id="CVE-2024-28168" title="CVE-2024-28168" type="cve"></reference>
          </references>
          <description>Improper Restriction of XML External Entity Reference (&#39;XXE&#39;) 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.(CVE-2024-28168)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="fop" release="9.oe2203sp1" version="2.2">
                         <filename>fop-2.2-9.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2244</id>
          <title>An update for poppler is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-4141" id="CVE-2024-4141" title="CVE-2024-4141" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-4141)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="poppler" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-cpp-devel" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debuginfo" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-debugsource" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-devel" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-devel-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-glib-devel" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-qt5-devel" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="poppler-utils" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-utils-0.90.0-9.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-glib-doc" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-doc-0.90.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="poppler-help" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-help-0.90.0-9.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-cpp-devel" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-cpp-devel-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debuginfo" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-debuginfo-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-debugsource" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-debugsource-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-devel" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-devel-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-glib-devel" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-glib-devel-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-qt5-devel" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-qt5-devel-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="poppler-utils" release="9.oe2203sp1" version="0.90.0">
                         <filename>poppler-utils-0.90.0-9.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2245</id>
          <title>An update for opensc is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45615" id="CVE-2024-45615" title="CVE-2024-45615" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45616" id="CVE-2024-45616" title="CVE-2024-45616" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45617" id="CVE-2024-45617" title="CVE-2024-45617" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45618" id="CVE-2024-45618" title="CVE-2024-45618" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45619" id="CVE-2024-45619" title="CVE-2024-45619" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45620" id="CVE-2024-45620" title="CVE-2024-45620" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8443" id="CVE-2024-8443" title="CVE-2024-8443" type="cve"></reference>
          </references>
          <description>A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. The problem is missing  initialization of variables expected to be initialized (as arguments to other functions, etc.).(CVE-2024-45615)A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. The following problems were caused by insufficient control of the response APDU buffer and its length when communicating with the card.(CVE-2024-45616)A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. Insufficient or missing checking of return values of functions leads to unexpected work with variables that have not been initialized.(CVE-2024-45617)A vulnerability was found in pkcs15-init in OpenSC. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. Insufficient or missing checking of return values of functions leads to unexpected work with variables that have not been initialized.(CVE-2024-45618)A vulnerability was found in OpenSC, OpenSC tools, PKCS#11 module, minidriver, and CTK. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. When buffers are partially filled with data, initialized parts of the buffer can be incorrectly accessed.(CVE-2024-45619)A vulnerability was found in the pkcs15-init tool in OpenSC. An attacker could use a crafted USB Device or Smart Card, which would present the system with a specially crafted response to APDUs. When buffers are partially filled with data, initialized parts of the buffer can be incorrectly accessed.(CVE-2024-45620)A heap-based buffer overflow vulnerability was found in the libopensc OpenPGP driver. A crafted USB device or smart card with malicious responses to the APDUs during the card enrollment process using the `pkcs15-init` tool may lead to out-of-bound rights, possibly resulting in arbitrary code execution.(CVE-2024-8443)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="opensc" release="11.oe2203sp1" version="0.21.0">
                         <filename>opensc-0.21.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="opensc-debuginfo" release="11.oe2203sp1" version="0.21.0">
                         <filename>opensc-debuginfo-0.21.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="opensc-debugsource" release="11.oe2203sp1" version="0.21.0">
                         <filename>opensc-debugsource-0.21.0-11.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="opensc-help" release="11.oe2203sp1" version="0.21.0">
                         <filename>opensc-help-0.21.0-11.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opensc" release="11.oe2203sp1" version="0.21.0">
                         <filename>opensc-0.21.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opensc-debuginfo" release="11.oe2203sp1" version="0.21.0">
                         <filename>opensc-debuginfo-0.21.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="opensc-debugsource" release="11.oe2203sp1" version="0.21.0">
                         <filename>opensc-debugsource-0.21.0-11.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2246</id>
          <title>An update for cups-filters is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47076" id="CVE-2024-47076" title="CVE-2024-47076" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47175" id="CVE-2024-47175" title="CVE-2024-47175" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47176" id="CVE-2024-47176" title="CVE-2024-47176" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47850" id="CVE-2024-47850" title="CVE-2024-47850" type="cve"></reference>
          </references>
          <description>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-47076)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-47175)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.(CVE-2024-47176)CUPS cups-browsed before 2.5b1 will send an HTTP POST request to an arbitrary destination and port in response to a single IPP UDP packet requesting a printer to be added, a different vulnerability than CVE-2024-47176. (The request is meant to probe the new printer but can be used to create DDoS amplification attacks.)(CVE-2024-47850)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="cups-filters" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-1.28.9-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters-debuginfo" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-debuginfo-1.28.9-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters-debugsource" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-debugsource-1.28.9-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="cups-filters-devel" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-devel-1.28.9-5.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="cups-filters-help" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-help-1.28.9-5.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-1.28.9-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-debuginfo" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-debuginfo-1.28.9-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-debugsource" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-debugsource-1.28.9-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="cups-filters-devel" release="5.oe2203sp1" version="1.28.9">
                         <filename>cups-filters-devel-1.28.9-5.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2248</id>
          <title>An update for php is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8925" id="CVE-2024-8925" title="CVE-2024-8925" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8926" id="CVE-2024-8926" title="CVE-2024-8926" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8927" id="CVE-2024-8927" title="CVE-2024-8927" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-9026" id="CVE-2024-9026" title="CVE-2024-9026" type="cve"></reference>
          </references>
          <description>PHP is an HTML-embedded scripting language. PHP attempts to make it easy for developers to write dynamically generated web pages. PHP also offers built-in database integration for several commercial and non-commercial database management systems, so writing a database-enabled webpage with PHP is fairly simple. The most common use of PHP coding is probably as a replacement for CGI scripts. The php package contains the module (often referred to as mod_php) which adds support for the PHP language to Apache HTTP Server.Security Fix(es):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-8925)In PHP versions 8.1.* before 8.1.30, 8.2.* before 8.2.24, 8.3.* before 8.3.12, when using a certain non-standard configurations of Windows codepages, the fixes for  CVE-2024-4577 https://github.com/advisories/GHSA-vxpp-6299-mxw3  may still be bypassed and the same command injection related to Windows &#34;Best Fit&#34; codepage behavior can be achieved. This may allow a malicious user to pass options to PHP binary being run, and thus reveal the source code of scripts, run arbitrary PHP code on the server, etc.(CVE-2024-8926)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-8927)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.(CVE-2024-9026)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="php" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-bcmath" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-cli" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-common" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dba" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-dbg" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debuginfo" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-debugsource" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-devel" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-embedded" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-enchant" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ffi" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-fpm" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gd" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-gmp" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-help" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-intl" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-ldap" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mbstring" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-mysqlnd" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-odbc" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-opcache" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pdo" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-pgsql" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-process" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-snmp" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-soap" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-sodium" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-tidy" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="php-xml" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-bcmath" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-bcmath-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-cli" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-cli-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-common" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-common-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dba" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-dba-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-dbg" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-dbg-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debuginfo" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-debuginfo-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-debugsource" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-debugsource-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-devel" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-devel-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-embedded" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-embedded-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-enchant" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-enchant-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ffi" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-ffi-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-fpm" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-fpm-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gd" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-gd-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-gmp" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-gmp-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-help" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-help-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-intl" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-intl-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-ldap" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-ldap-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mbstring" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-mbstring-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-mysqlnd" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-mysqlnd-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-odbc" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-odbc-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-opcache" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-opcache-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pdo" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-pdo-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-pgsql" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-pgsql-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-process" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-process-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-snmp" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-snmp-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-soap" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-soap-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-sodium" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-sodium-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-tidy" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-tidy-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="php-xml" release="6.oe2203sp1" version="8.0.30">
                         <filename>php-xml-8.0.30-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2250</id>
          <title>An update for rubygem-puma is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-10-12"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-24790" id="CVE-2022-24790" title="CVE-2022-24790" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-40175" id="CVE-2023-40175" title="CVE-2023-40175" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-21647" id="CVE-2024-21647" title="CVE-2024-21647" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45614" id="CVE-2024-45614" title="CVE-2024-45614" type="cve"></reference>
          </references>
          <description>Puma is a simple, fast, multi-threaded, parallel HTTP 1.1 server for Ruby/Rack applications. When using Puma behind a proxy that does not properly validate that the incoming HTTP request matches the RFC7230 standard, Puma and the frontend proxy may disagree on where a request starts and ends. This would allow requests to be smuggled via the front-end proxy to Puma. The vulnerability has been fixed in 5.6.4 and 4.3.12. Users are advised to upgrade as soon as possible. Workaround: when deploying a proxy in front of Puma, turning on any and all functionality to make sure that the request matches the RFC7230 standard.(CVE-2022-24790)Puma is a Ruby/Rack web server built for parallelism. Prior to versions 6.3.1 and 5.6.7, puma exhibited incorrect behavior when parsing chunked transfer encoding bodies and zero-length Content-Length headers in a way that allowed HTTP request smuggling. Severity of this issue is highly dependent on the nature of the web site using puma is. This could be caused by either incorrect parsing of trailing fields in chunked transfer encoding bodies or by parsing of blank/zero-length Content-Length headers. Both issues have been addressed and this vulnerability has been fixed in versions 6.3.1 and 5.6.7. Users are advised to upgrade. There are no known workarounds for this vulnerability.(CVE-2023-40175)Puma is a web server for Ruby/Rack applications built for parallelism. Prior to version 6.4.2, puma exhibited incorrect behavior when parsing chunked transfer encoding bodies in a way that allowed HTTP request smuggling. Fixed versions limits the size of chunk extensions. Without this limit, an attacker could cause unbounded resource (CPU, network bandwidth) consumption. This vulnerability has been fixed in versions 6.4.2 and 5.6.8.(CVE-2024-21647)Puma is a Ruby/Rack web server built for parallelism. In affected versions clients could clobber values set by intermediate proxies (such as X-Forwarded-For) by providing a underscore version of the same header (X-Forwarded_For). Any users relying on proxy set variables is affected. v6.4.3/v5.6.9 now discards any headers using underscores if the non-underscore version also exists. Effectively, allowing the proxy defined headers to always win. Users are advised to upgrade. Nginx has a underscores_in_headers configuration variable to discard these headers at the proxy level as a mitigation. Any users that are implicitly trusting the proxy defined headers for security should immediately cease doing so until upgraded to the fixed versions.(CVE-2024-45614)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="rubygem-puma" release="3.oe2203sp1" version="5.6.5">
                         <filename>rubygem-puma-5.6.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-puma-debuginfo" release="3.oe2203sp1" version="5.6.5">
                         <filename>rubygem-puma-debuginfo-5.6.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="rubygem-puma-debugsource" release="3.oe2203sp1" version="5.6.5">
                         <filename>rubygem-puma-debugsource-5.6.5-3.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="rubygem-puma-doc" release="3.oe2203sp1" version="5.6.5">
                         <filename>rubygem-puma-doc-5.6.5-3.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma" release="3.oe2203sp1" version="5.6.5">
                         <filename>rubygem-puma-5.6.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma-debuginfo" release="3.oe2203sp1" version="5.6.5">
                         <filename>rubygem-puma-debuginfo-5.6.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="rubygem-puma-debugsource" release="3.oe2203sp1" version="5.6.5">
                         <filename>rubygem-puma-debugsource-5.6.5-3.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2257</id>
          <title>An update for kernel is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Critical</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48688" id="CVE-2022-48688" title="CVE-2022-48688" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48848" id="CVE-2022-48848" title="CVE-2022-48848" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48869" id="CVE-2022-48869" title="CVE-2022-48869" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48879" id="CVE-2022-48879" title="CVE-2022-48879" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48893" id="CVE-2022-48893" title="CVE-2022-48893" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-48945" id="CVE-2022-48945" title="CVE-2022-48945" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-0597" id="CVE-2023-0597" title="CVE-2023-0597" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-4134" id="CVE-2023-4134" title="CVE-2023-4134" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52463" id="CVE-2023-52463" title="CVE-2023-52463" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52707" id="CVE-2023-52707" title="CVE-2023-52707" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52741" id="CVE-2023-52741" title="CVE-2023-52741" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-52880" id="CVE-2023-52880" title="CVE-2023-52880" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-36031" id="CVE-2024-36031" title="CVE-2024-36031" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-40998" id="CVE-2024-40998" title="CVE-2024-40998" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42067" id="CVE-2024-42067" title="CVE-2024-42067" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42283" id="CVE-2024-42283" title="CVE-2024-42283" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42290" id="CVE-2024-42290" title="CVE-2024-42290" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42309" id="CVE-2024-42309" title="CVE-2024-42309" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42313" id="CVE-2024-42313" title="CVE-2024-42313" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42322" id="CVE-2024-42322" title="CVE-2024-42322" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43823" id="CVE-2024-43823" title="CVE-2024-43823" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43830" id="CVE-2024-43830" title="CVE-2024-43830" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43855" id="CVE-2024-43855" title="CVE-2024-43855" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43892" id="CVE-2024-43892" title="CVE-2024-43892" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-43893" id="CVE-2024-43893" title="CVE-2024-43893" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44940" id="CVE-2024-44940" title="CVE-2024-44940" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-44998" id="CVE-2024-44998" title="CVE-2024-44998" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45006" id="CVE-2024-45006" title="CVE-2024-45006" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45026" id="CVE-2024-45026" title="CVE-2024-45026" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46676" id="CVE-2024-46676" title="CVE-2024-46676" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46719" id="CVE-2024-46719" title="CVE-2024-46719" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46754" id="CVE-2024-46754" title="CVE-2024-46754" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46770" id="CVE-2024-46770" title="CVE-2024-46770" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46795" id="CVE-2024-46795" title="CVE-2024-46795" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46819" id="CVE-2024-46819" title="CVE-2024-46819" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46828" id="CVE-2024-46828" title="CVE-2024-46828" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46840" id="CVE-2024-46840" title="CVE-2024-46840" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46848" id="CVE-2024-46848" title="CVE-2024-46848" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46854" id="CVE-2024-46854" title="CVE-2024-46854" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46855" id="CVE-2024-46855" title="CVE-2024-46855" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-46858" id="CVE-2024-46858" title="CVE-2024-46858" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47658" id="CVE-2024-47658" title="CVE-2024-47658" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47664" id="CVE-2024-47664" title="CVE-2024-47664" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47670" id="CVE-2024-47670" title="CVE-2024-47670" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47671" id="CVE-2024-47671" title="CVE-2024-47671" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-47672" id="CVE-2024-47672" title="CVE-2024-47672" type="cve"></reference>
          </references>
          <description>In the Linux kernel, the following vulnerability has been resolved:i40e: Fix kernel crash during module removalThe driver incorrectly frees client instance and subsequenti40e module removal leads to kernel crash.Reproducer:1. Do ethtool offline test followed immediately by another onehost# ethtool -t eth0 offline; ethtool -t eth0 offline2. Remove recursively irdma module that also removes i40e modulehost# modprobe -r irdmaResult:[ 8675.035651] i40e 0000:3d:00.0 eno1: offline testing starting[ 8675.193774] i40e 0000:3d:00.0 eno1: testing finished[ 8675.201316] i40e 0000:3d:00.0 eno1: offline testing starting[ 8675.358921] i40e 0000:3d:00.0 eno1: testing finished[ 8675.496921] i40e 0000:3d:00.0: IRDMA hardware initialization FAILED init_state=2 status=-110[ 8686.188955] i40e 0000:3d:00.1: i40e_ptp_stop: removed PHC on eno2[ 8686.943890] i40e 0000:3d:00.1: Deleted LAN device PF1 bus=0x3d dev=0x00 func=0x01[ 8686.952669] i40e 0000:3d:00.0: i40e_ptp_stop: removed PHC on eno1[ 8687.761787] BUG: kernel NULL pointer dereference, address: 0000000000000030[ 8687.768755] #PF: supervisor read access in kernel mode[ 8687.773895] #PF: error_code(0x0000) - not-present page[ 8687.779034] PGD 0 P4D 0[ 8687.781575] Oops: 0000 [#1] PREEMPT SMP NOPTI[ 8687.785935] CPU: 51 PID: 172891 Comm: rmmod Kdump: loaded Tainted: G        W I        5.19.0+ #2[ 8687.794800] Hardware name: Intel Corporation S2600WFD/S2600WFD, BIOS SE5C620.86B.0X.02.0001.051420190324 05/14/2019[ 8687.805222] RIP: 0010:i40e_lan_del_device+0x13/0xb0 [i40e][ 8687.810719] Code: d4 84 c0 0f 84 b8 25 01 00 e9 9c 25 01 00 41 bc f4 ff ff ff eb 91 90 0f 1f 44 00 00 41 54 55 53 48 8b 87 58 08 00 00 48 89 fb &lt;48&gt; 8b 68 30 48 89 ef e8 21 8a 0f d5 48 89 ef e8 a9 78 0f d5 48 8b[ 8687.829462] RSP: 0018:ffffa604072efce0 EFLAGS: 00010202[ 8687.834689] RAX: 0000000000000000 RBX: ffff8f43833b2000 RCX: 0000000000000000[ 8687.841821] RDX: 0000000000000000 RSI: ffff8f4b0545b298 RDI: ffff8f43833b2000[ 8687.848955] RBP: ffff8f43833b2000 R08: 0000000000000001 R09: 0000000000000000[ 8687.856086] R10: 0000000000000000 R11: 000ffffffffff000 R12: ffff8f43833b2ef0[ 8687.863218] R13: ffff8f43833b2ef0 R14: ffff915103966000 R15: ffff8f43833b2008[ 8687.870342] FS:  00007f79501c3740(0000) GS:ffff8f4adffc0000(0000) knlGS:0000000000000000[ 8687.878427] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033[ 8687.884174] CR2: 0000000000000030 CR3: 000000014276e004 CR4: 00000000007706e0[ 8687.891306] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000[ 8687.898441] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400[ 8687.905572] PKRU: 55555554[ 8687.908286] Call Trace:[ 8687.910737]  &lt;TASK&gt;[ 8687.912843]  i40e_remove+0x2c0/0x330 [i40e][ 8687.917040]  pci_device_remove+0x33/0xa0[ 8687.920962]  device_release_driver_internal+0x1aa/0x230[ 8687.926188]  driver_detach+0x44/0x90[ 8687.929770]  bus_remove_driver+0x55/0xe0[ 8687.933693]  pci_unregister_driver+0x2a/0xb0[ 8687.937967]  i40e_exit_module+0xc/0xf48 [i40e]Two offline tests cause IRDMA driver failure (ETIMEDOUT) and thisfailure is indicated back to i40e_client_subtask() that callsi40e_client_del_instance() to free client instance referencedby pf-&gt;cinst and sets this pointer to NULL. During the moduleremoval i40e_remove() calls i40e_lan_del_device() that dereferencespf-&gt;cinst that is NULL -&gt; crash.Do not remove client instance when client open callbacks fails andjust clear __I40E_CLIENT_INSTANCE_OPENED bit. The driver also needsto take care about this situation (when netdev is up and clientis NOT opened) in i40e_notify_client_of_netdev_close() andcalls client close callback only when __I40E_CLIENT_INSTANCE_OPENEDis set.(CVE-2022-48688)In the Linux kernel, the following vulnerability has been resolved:tracing/osnoise: Do not unregister events twiceNicolas reported that using: # trace-cmd record -e all -M 10 -p osnoise --pollResulted in the following kernel warning: ------------[ cut here ]------------ WARNING: CPU: 0 PID: 1217 at kernel/tracepoint.c:404 tracepoint_probe_unregister+0x280/0x370 [...] CPU: 0 PID: 1217 Comm: trace-cmd Not tainted 5.17.0-rc6-next-20220307-nico+ #19 RIP: 0010:tracepoint_probe_unregister+0x280/0x370 [...] CR2: 00007ff919b29497 CR3: 0000000109da4005 CR4: 0000000000170ef0 Call Trace:  &lt;TASK&gt;  osnoise_workload_stop+0x36/0x90  tracing_set_tracer+0x108/0x260  tracing_set_trace_write+0x94/0xd0  ? __check_object_size.part.0+0x10a/0x150  ? selinux_file_permission+0x104/0x150  vfs_write+0xb5/0x290  ksys_write+0x5f/0xe0  do_syscall_64+0x3b/0x90  entry_SYSCALL_64_after_hwframe+0x44/0xae RIP: 0033:0x7ff919a18127 [...] ---[ end trace 0000000000000000 ]---The warning complains about an attempt to unregister anunregistered tracepoint.This happens on trace-cmd because it first stops tracing, andthen switches the tracer to nop. Which is equivalent to:  # cd /sys/kernel/tracing/  # echo osnoise &gt; current_tracer  # echo 0 &gt; tracing_on  # echo nop &gt; current_tracerThe osnoise tracer stops the workload when no trace instanceis actually collecting data. This can be caused both bydisabling tracing or disabling the tracer itself.To avoid unregistering events twice, use the existingtrace_osnoise_callback_enabled variable to check if the events(and the workload) are actually active before trying todeactivate them.(CVE-2022-48848)In the Linux kernel, the following vulnerability has been resolved:USB: gadgetfs: Fix race between mounting and unmountingThe syzbot fuzzer and Gerald Lee have identified a use-after-free bugin the gadgetfs driver, involving processes concurrently mounting andunmounting the gadgetfs filesystem.  In particular, gadgetfs_fill_super()can race with gadgetfs_kill_sb(), causing the latter to deallocatethe_device while the former is using it.  The output from KASAN says,in part:BUG: KASAN: use-after-free in instrument_atomic_read_write include/linux/instrumented.h:102 [inline]BUG: KASAN: use-after-free in atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline]BUG: KASAN: use-after-free in __refcount_sub_and_test include/linux/refcount.h:272 [inline]BUG: KASAN: use-after-free in __refcount_dec_and_test include/linux/refcount.h:315 [inline]BUG: KASAN: use-after-free in refcount_dec_and_test include/linux/refcount.h:333 [inline]BUG: KASAN: use-after-free in put_dev drivers/usb/gadget/legacy/inode.c:159 [inline]BUG: KASAN: use-after-free in gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086Write of size 4 at addr ffff8880276d7840 by task syz-executor126/18689CPU: 0 PID: 18689 Comm: syz-executor126 Not tainted 6.1.0-syzkaller #0Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/26/2022Call Trace: &lt;TASK&gt;... atomic_fetch_sub_release include/linux/atomic/atomic-instrumented.h:176 [inline] __refcount_sub_and_test include/linux/refcount.h:272 [inline] __refcount_dec_and_test include/linux/refcount.h:315 [inline] refcount_dec_and_test include/linux/refcount.h:333 [inline] put_dev drivers/usb/gadget/legacy/inode.c:159 [inline] gadgetfs_kill_sb+0x33/0x100 drivers/usb/gadget/legacy/inode.c:2086 deactivate_locked_super+0xa7/0xf0 fs/super.c:332 vfs_get_super fs/super.c:1190 [inline] get_tree_single+0xd0/0x160 fs/super.c:1207 vfs_get_tree+0x88/0x270 fs/super.c:1531 vfs_fsconfig_locked fs/fsopen.c:232 [inline]The simplest solution is to ensure that gadgetfs_fill_super() andgadgetfs_kill_sb() are serialized by making them both acquire a newmutex.(CVE-2022-48869)In the Linux kernel, the following vulnerability has been resolved:efi: fix NULL-deref in init error pathIn 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 unlikelyevent that EFI initialisation fails to avoid dereferencing a NULLpointer.(CVE-2022-48879)In the Linux kernel, the following vulnerability has been resolved:drm/i915/gt: Cleanup partial engine discovery failuresIf we abort driver initialisation in the middle of gt/engine discovery,some engines will be fully setup and some not. Those incompletely setupengines only have &#39;engine-&gt;release == NULL&#39; and so will leak any of thecommon objects allocated.v2: - Drop the destroy_pinned_context() helper for now.  It&#39;s not really   worth it with just a single callsite at the moment.  (Janusz)(CVE-2022-48893)In the Linux kernel, the following vulnerability has been resolved:media: vivid: fix compose size exceed boundarysyzkaller found a bug: BUG: unable to handle page fault for address: ffffc9000a3b1000 #PF: supervisor write access in kernel mode #PF: error_code(0x0002) - not-present page PGD 100000067 P4D 100000067 PUD 10015f067 PMD 1121ca067 PTE 0 Oops: 0002 [#1] PREEMPT SMP CPU: 0 PID: 23489 Comm: vivid-000-vid-c Not tainted 6.1.0-rc1+ #512 Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.13.0-1ubuntu1.1 04/01/2014 RIP: 0010:memcpy_erms+0x6/0x10[...] Call Trace:  &lt;TASK&gt;  ? tpg_fill_plane_buffer+0x856/0x15b0  vivid_fillbuff+0x8ac/0x1110  vivid_thread_vid_cap_tick+0x361/0xc90  vivid_thread_vid_cap+0x21a/0x3a0  kthread+0x143/0x180  ret_from_fork+0x1f/0x30  &lt;/TASK&gt;This is because we forget to check boundary after adjust compose-&gt;heightint V4L2_SEL_TGT_CROP case. Add v4l2_rect_map_inside() to fix this problemfor this case.(CVE-2022-48945)A flaw possibility of memory leak in the Linux kernel cpu_entry_area mapping of X86 CPU data to memory was found in the way user can guess location of exception stack(s) or other important data. A local user could use this flaw to get access to some important data with expected location in memory.(CVE-2023-0597)From the upstream fix below: The watchdog_timer can schedule tx_timeout_task and watchdog_work can also arm watchdog_timer [..] Although del_timer_sync() and cancel_work_sync() are called in cyttsp4_remove(), the timer and workqueue could still be rearmed. As a result, the possible use after free bugs could happen.Upstream commit:https://github.com/torvalds/linux/commit/dbe836576f12743a7d2d170ad4ad4fd324c4d47a(CVE-2023-4134)In the Linux kernel, the following vulnerability has been resolved:efivarfs: force RO when remounting if SetVariable is not supportedIf SetVariable at runtime is not supported by the firmware we never assigna callback for that function. At the same time mount the efivarfs asRO so no one can call that.  However, we never check the permission flagswhen someone remounts the filesystem as RW. As a result this leads to acrash 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 whichwe can use to check the requested flags and deny anything that&#39;s not ROif the firmware doesn&#39;t implement SetVariable at runtime.(CVE-2023-52463)In the Linux kernel, the following vulnerability has been resolved:sched/psi: Fix use-after-free in ep_remove_wait_queue()If a non-root cgroup gets removed when there is a thread that registeredtrigger and is polling on a pressure file within the cgroup, the pollingwaitqueue gets freed in the following path: do_rmdir   cgroup_rmdir     kernfs_drain_open_files       cgroup_file_release         cgroup_pressure_release           psi_trigger_destroyHowever, the polling thread still has a reference to the pressure file andwill access the freed waitqueue when the file is closed or upon exit: fput   ep_eventpoll_release     ep_free       ep_remove_wait_queue         remove_wait_queueThis results in use-after-free as pasted below.The fundamental problem here is that cgroup_file_release() (andconsequently waitqueue&#39;s lifetime) is not tied to the file&#39;s real lifetime.Using wake_up_pollfree() here might be less than ideal, but it is in linewith the comment at commit 42288cb44c4b (&#34;wait: add wake_up_pollfree()&#34;)since the waitqueue&#39;s lifetime is not tied to file&#39;s one and can beconsidered as another special case. While this would be fixable by somehowmaking cgroup_file_release() be tied to the fput(), it would requiresizable refactoring at cgroups or higher layer which might be morejustifiable if we identify more cases like this.  BUG: KASAN: use-after-free in _raw_spin_lock_irqsave+0x60/0xc0  Write of size 4 at addr ffff88810e625328 by task a.out/4404&#x9;CPU: 19 PID: 4404 Comm: a.out Not tainted 6.2.0-rc6 #38&#x9;Hardware name: Amazon EC2 c5a.8xlarge/, BIOS 1.0 10/16/2017&#x9;Call Trace:&#x9;&lt;TASK&gt;&#x9;dump_stack_lvl+0x73/0xa0&#x9;print_report+0x16c/0x4e0&#x9;kasan_report+0xc3/0xf0&#x9;kasan_check_range+0x2d2/0x310&#x9;_raw_spin_lock_irqsave+0x60/0xc0&#x9;remove_wait_queue+0x1a/0xa0&#x9;ep_free+0x12c/0x170&#x9;ep_eventpoll_release+0x26/0x30&#x9;__fput+0x202/0x400&#x9;task_work_run+0x11d/0x170&#x9;do_exit+0x495/0x1130&#x9;do_group_exit+0x100/0x100&#x9;get_signal+0xd67/0xde0&#x9;arch_do_signal_or_restart+0x2a/0x2b0&#x9;exit_to_user_mode_prepare+0x94/0x100&#x9;syscall_exit_to_user_mode+0x20/0x40&#x9;do_syscall_64+0x52/0x90&#x9;entry_SYSCALL_64_after_hwframe+0x63/0xcd&#x9;&lt;/TASK&gt; Allocated by task 4404:&#x9;kasan_set_track+0x3d/0x60&#x9;__kasan_kmalloc+0x85/0x90&#x9;psi_trigger_create+0x113/0x3e0&#x9;pressure_write+0x146/0x2e0&#x9;cgroup_file_write+0x11c/0x250&#x9;kernfs_fop_write_iter+0x186/0x220&#x9;vfs_write+0x3d8/0x5c0&#x9;ksys_write+0x90/0x110&#x9;do_syscall_64+0x43/0x90&#x9;entry_SYSCALL_64_after_hwframe+0x63/0xcd Freed by task 4407:&#x9;kasan_set_track+0x3d/0x60&#x9;kasan_save_free_info+0x27/0x40&#x9;____kasan_slab_free+0x11d/0x170&#x9;slab_free_freelist_hook+0x87/0x150&#x9;__kmem_cache_free+0xcb/0x180&#x9;psi_trigger_destroy+0x2e8/0x310&#x9;cgroup_file_release+0x4f/0xb0&#x9;kernfs_drain_open_files+0x165/0x1f0&#x9;kernfs_drain+0x162/0x1a0&#x9;__kernfs_remove+0x1fb/0x310&#x9;kernfs_remove_by_name_ns+0x95/0xe0&#x9;cgroup_addrm_files+0x67f/0x700&#x9;cgroup_destroy_locked+0x283/0x3c0&#x9;cgroup_rmdir+0x29/0x100&#x9;kernfs_iop_rmdir+0xd1/0x140&#x9;vfs_rmdir+0xfe/0x240&#x9;do_rmdir+0x13d/0x280&#x9;__x64_sys_rmdir+0x2c/0x30&#x9;do_syscall_64+0x43/0x90&#x9;entry_SYSCALL_64_after_hwframe+0x63/0xcd(CVE-2023-52707)In the Linux kernel, the following vulnerability has been resolved:cifs: Fix use-after-free in rdata-&gt;read_into_pages()When the network status is unstable, use-after-free may occur whenread data from the server.  BUG: KASAN: use-after-free in readpages_fill_pages+0x14c/0x7e0  Call Trace:   &lt;TASK&gt;   dump_stack_lvl+0x38/0x4c   print_report+0x16f/0x4a6   kasan_report+0xb7/0x130   readpages_fill_pages+0x14c/0x7e0   cifs_readv_receive+0x46d/0xa40   cifs_demultiplex_thread+0x121c/0x1490   kthread+0x16b/0x1a0   ret_from_fork+0x2c/0x50   &lt;/TASK&gt;  Allocated by task 2535:   kasan_save_stack+0x22/0x50   kasan_set_track+0x25/0x30   __kasan_kmalloc+0x82/0x90   cifs_readdata_direct_alloc+0x2c/0x110   cifs_readdata_alloc+0x2d/0x60   cifs_readahead+0x393/0xfe0   read_pages+0x12f/0x470   page_cache_ra_unbounded+0x1b1/0x240   filemap_get_pages+0x1c8/0x9a0   filemap_read+0x1c0/0x540   cifs_strict_readv+0x21b/0x240   vfs_read+0x395/0x4b0   ksys_read+0xb8/0x150   do_syscall_64+0x3f/0x90   entry_SYSCALL_64_after_hwframe+0x72/0xdc  Freed by task 79:   kasan_save_stack+0x22/0x50   kasan_set_track+0x25/0x30   kasan_save_free_info+0x2e/0x50   __kasan_slab_free+0x10e/0x1a0   __kmem_cache_free+0x7a/0x1a0   cifs_readdata_release+0x49/0x60   process_one_work+0x46c/0x760   worker_thread+0x2a4/0x6f0   kthread+0x16b/0x1a0   ret_from_fork+0x2c/0x50  Last potentially related work creation:   kasan_save_stack+0x22/0x50   __kasan_record_aux_stack+0x95/0xb0   insert_work+0x2b/0x130   __queue_work+0x1fe/0x660   queue_work_on+0x4b/0x60   smb2_readv_callback+0x396/0x800   cifs_abort_connection+0x474/0x6a0   cifs_reconnect+0x5cb/0xa50   cifs_readv_from_socket.cold+0x22/0x6c   cifs_read_page_from_socket+0xc1/0x100   readpages_fill_pages.cold+0x2f/0x46   cifs_readv_receive+0x46d/0xa40   cifs_demultiplex_thread+0x121c/0x1490   kthread+0x16b/0x1a0   ret_from_fork+0x2c/0x50The following function calls will cause UAF of the rdata pointer.readpages_fill_pages cifs_read_page_from_socket  cifs_readv_from_socket   cifs_reconnect    __cifs_reconnect     cifs_abort_connection      mid-&gt;callback() --&gt; smb2_readv_callback       queue_work(&amp;rdata-&gt;work)  # if the worker completes first,                                 # the rdata is freed          cifs_readv_complete            kref_put              cifs_readdata_release                kfree(rdata) return rdata-&gt;...               # UAF in readpages_fill_pages()Similarly, this problem also occurs in the uncache_fill_pages().Fix this by adjusts the order of condition judgment in the returnstatement.(CVE-2023-52741)In the Linux kernel, the following vulnerability has been resolved:tty: n_gsm: require CAP_NET_ADMIN to attach N_GSM0710 ldiscAny unprivileged user can attach N_GSM0710 ldisc, but it requiresCAP_NET_ADMIN to create a GSM network anyway.Require initial namespace CAP_NET_ADMIN to do that.(CVE-2023-52880)In the Linux kernel, the following vulnerability has been resolved:keys: Fix overwrite of key expiration on instantiationThe expiry time of a key is unconditionally overwritten duringinstantiation, defaulting to turn it permanent. This causes a problemfor DNS resolution as the expiration set by user-space is overwritten toTIME64_MAX, disabling further DNS updates. Fix this by restoring thecondition that key_set_expiry is only called when the pre-parser sets aspecific expiry.(CVE-2024-36031)In the Linux kernel, the following vulnerability has been resolved:ext4: fix uninitialized ratelimit_state-&gt;lock access in __ext4_fill_super()In the following concurrency we will access the uninitialized rs-&gt;lock:ext4_fill_super  ext4_register_sysfs   // sysfs registered msg_ratelimit_interval_ms                             // Other processes modify rs-&gt;interval to                             // non-zero via msg_ratelimit_interval_ms  ext4_orphan_cleanup    ext4_msg(sb, KERN_INFO, &#34;Errors on filesystem, &#34;      __ext4_msg        ___ratelimit(&amp;(EXT4_SB(sb)-&gt;s_msg_ratelimit_state)          if (!rs-&gt;interval)  // do nothing if interval is 0            return 1;          raw_spin_trylock_irqsave(&amp;rs-&gt;lock, flags)            raw_spin_trylock(lock)              _raw_spin_trylock                __raw_spin_trylock                  spin_acquire(&amp;lock-&gt;dep_map, 0, 1, _RET_IP_)                    lock_acquire                      __lock_acquire                        register_lock_class                          assign_lock_key                            dump_stack();  ratelimit_state_init(&amp;sbi-&gt;s_msg_ratelimit_state, 5 * HZ, 10);    raw_spin_lock_init(&amp;rs-&gt;lock);    // init rs-&gt;lock hereand get the following dump_stack:=========================================================INFO: trying to register non-static key.The code is fine but needs lockdep annotation, or maybeyou didn&#39;t initialize this object before use?turning off the locking correctness validator.CPU: 12 PID: 753 Comm: mount Tainted: G E 6.7.0-rc6-next-20231222 #504[...]Call Trace: dump_stack_lvl+0xc5/0x170 dump_stack+0x18/0x30 register_lock_class+0x740/0x7c0 __lock_acquire+0x69/0x13a0 lock_acquire+0x120/0x450 _raw_spin_trylock+0x98/0xd0 ___ratelimit+0xf6/0x220 __ext4_msg+0x7f/0x160 [ext4] ext4_orphan_cleanup+0x665/0x740 [ext4] __ext4_fill_super+0x21ea/0x2b10 [ext4] ext4_fill_super+0x14d/0x360 [ext4][...]=========================================================Normally interval is 0 until s_msg_ratelimit_state is initialized, so___ratelimit() does nothing. But registering sysfs precedes initializingrs-&gt;lock, so it is possible to change rs-&gt;interval to a non-zero valuevia the msg_ratelimit_interval_ms interface of sysfs while rs-&gt;lock isuninitialized, and then a call to ext4_msg triggers the problem byaccessing an uninitialized rs-&gt;lock. Therefore register sysfs after allinitializations are complete to avoid such problems.(CVE-2024-40998)In the Linux kernel, the following vulnerability has been resolved:bpf: Take return from set_memory_rox() into account with bpf_jit_binary_lock_ro()set_memory_rox() can fail, leaving memory unprotected.Check return and bail out when bpf_jit_binary_lock_ro() returnsan error.(CVE-2024-42067)In the Linux kernel, the following vulnerability has been resolved:net: nexthop: Initialize all fields in dumped nexthopsstruct nexthop_grp contains two reserved fields that are not initialized bynla_put_nh_group(), and carry garbage. This can be observed e.g. withstrace (edited for clarity):    # ip nexthop add id 1 dev lo    # ip nexthop add id 101 group 1    # strace -e recvmsg ip nexthop get id 101    ...    recvmsg(... [{nla_len=12, nla_type=NHA_GROUP},                 [{id=1, weight=0, resvd1=0x69, resvd2=0x67}]] ...) = 52The fields are reserved and therefore not currently used. But as they are, theyleak kernel memory, and the fact they are not just zero complicates repurposingof the fields for new ends. Initialize the full structure.(CVE-2024-42283)In the Linux kernel, the following vulnerability has been resolved:irqchip/imx-irqsteer: Handle runtime power management correctlyThe power domain is automatically activated from clk_prepare(). However, oncertain platforms like i.MX8QM and i.MX8QXP, the power-on handling invokessleeping functions, which triggers the &#39;scheduling while atomic&#39; bug in thecontext 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/0x4b0Cure this by implementing the irq_bus_lock/sync_unlock() interrupt chipcallbacks and handle power management in them as they are invoked fromnon-atomic context.[ tglx: Rewrote change log, added Fixes tag ](CVE-2024-42290)In the Linux kernel, the following vulnerability has been resolved:drm/gma500: fix null pointer dereference in psb_intel_lvds_get_modesIn psb_intel_lvds_get_modes(), the return value of drm_mode_duplicate() isassigned to mode, which will lead to a possible NULL pointer dereferenceon failure of drm_mode_duplicate(). Add a check to avoid npd.(CVE-2024-42309)In the Linux kernel, the following vulnerability has been resolved:media: venus: fix use after free in vdec_closeThere appears to be a possible use after free with vdec_close().The firmware will add buffer release work to the work queue throughHFI callbacks as a normal part of decoding. Randomly closing thedecoder device from userspace during normal decoding can incura read after free for inst.Fix it by cancelling the work in vdec_close.(CVE-2024-42313)In the Linux kernel, the following vulnerability has been resolved:ipvs: properly dereference pe in ip_vs_add_serviceUse pe directly to resolve sparse warning:  net/netfilter/ipvs/ip_vs_ctl.c:1471:27: warning: dereference of noderef expression(CVE-2024-42322)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 toany error, resource_list_first_type() will return NULL andpci_parse_request_of_pci_ranges() will just emit a warning.This will cause a NULL pointer dereference. Fix this bug by adding NULLreturn check.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-43823)In the Linux kernel, the following vulnerability has been resolved:leds: trigger: Unregister sysfs attributes before calling deactivate()Triggers which have trigger specific sysfs attributes typically storerelated data in trigger-data allocated by the activate() callback andfreed by the deactivate() callback.Calling device_remove_groups() after calling deactivate() leaves a windowwhere the sysfs attributes show/store functions could be called afterdeactivation and then operate on the just freed trigger-data.Move the device_remove_groups() call to before deactivate() to closethis race window.This also makes the deactivation path properly do things in reverse orderof the activation path which calls the activate() callback before callingdevice_add_groups().(CVE-2024-43830)In the Linux kernel, the following vulnerability has been resolved:md: fix deadlock between mddev_suspend and flush bioDeadlock occurs when mddev is being suspended while some flush bio is inprogress. It is a complex issue.T1. the first flush is at the ending stage, it clears &#39;mddev-&gt;flush_bio&#39;    and tries to submit data, but is blocked because mddev is suspended    by T4.T2. the second flush sets &#39;mddev-&gt;flush_bio&#39;, and attempts to queue    md_submit_flush_data(), which is already running (T1) and won&#39;t    execute again if on the same CPU as T1.T3. the third flush inc active_io and tries to flush, but is blocked because    &#39;mddev-&gt;flush_bio&#39; is not NULL (set by T2).T4. mddev_suspend() is called and waits for active_io dec to 0 which is inc    by T3.  T1&#x9;&#x9;T2&#x9;&#x9;T3&#x9;&#x9;T4  (flush 1)&#x9;(flush 2)&#x9;(third 3)&#x9;(suspend)  md_submit_flush_data   mddev-&gt;flush_bio = NULL;   .   .&#x9; &#x9;md_flush_request   .&#x9;  &#x9; mddev-&gt;flush_bio = bio   .&#x9;  &#x9; queue submit_flushes   .&#x9;&#x9; .   .&#x9;&#x9; .&#x9;&#x9;md_handle_request   .&#x9;&#x9; .&#x9;&#x9; active_io + 1   .&#x9;&#x9; .&#x9;&#x9; md_flush_request   .&#x9;&#x9; .&#x9;&#x9;  wait !mddev-&gt;flush_bio   .&#x9;&#x9; .   .&#x9;&#x9; .&#x9;&#x9;&#x9;&#x9;mddev_suspend   .&#x9;&#x9; .&#x9;&#x9;&#x9;&#x9; wait !active_io   .&#x9;&#x9; .   .&#x9;&#x9; submit_flushes   .&#x9;&#x9; queue_work md_submit_flush_data   .&#x9;&#x9; //md_submit_flush_data is already running (T1)   .   md_handle_request    wait resumeThe root issue is non-atomic inc/dec of active_io during flush process.active_io is dec before md_submit_flush_data is queued, and inc soonafter md_submit_flush_data() run.  md_flush_request    active_io + 1    submit_flushes      active_io - 1      md_submit_flush_data        md_handle_request        active_io + 1          make_request        active_io - 1If active_io is dec after md_handle_request() instead of withinsubmit_flushes(), make_request() can be called directly intead ofmd_handle_request() in md_submit_flush_data(), and active_io willonly inc and dec once in the whole flush process. Deadlock will befixed.Additionally, the only difference between fixing the issue and before isthat there is no return error handling of make_request(). But afterprevious patch cleaned md_write_start(), make_requst() only return errorin raid5_make_request() by dm-raid, see commit 41425f96d7aa (&#34;dm-raid456,md/raid456: fix a deadlock for dm-raid456 while io concurrent withreshape)&#34;. Since dm always splits data and flush operation into twoseparate io, io size of flush submitted by dm always is 0, make_request()will not be called in md_submit_flush_data(). To prevent futuremodifications from introducing issues, add WARN_ON to ensuremake_request() no error is returned in this context.(CVE-2024-43855)In the Linux kernel, the following vulnerability has been resolved:memcg: protect concurrent access to mem_cgroup_idrCommit 73f576c04b94 (&#34;mm: memcontrol: fix cgroup creation failure aftermany small jobs&#34;) decoupled the memcg IDs from the CSS ID space to fix thecgroup creation failures.  It introduced IDR to maintain the memcg IDspace.  The IDR depends on external synchronization mechanisms formodifications.  For the mem_cgroup_idr, the idr_alloc() and idr_replace()happen within css callback and thus are protected through cgroup_mutexfrom concurrent modifications.  However idr_remove() for mem_cgroup_idrwas not protected against concurrency and can be run concurrently fordifferent memcgs when they hit their refcnt to zero.  Fix that.We have been seeing list_lru based kernel crashes at a low frequency inour fleet for a long time.  These crashes were in different part oflist_lru code including list_lru_add(), list_lru_del() and reparentingcode.  Upon further inspection, it looked like for a given object (dentryand inode), the super_block&#39;s list_lru didn&#39;t have list_lru_one for thememcg of that object.  The initial suspicions were either the object isnot allocated through kmem_cache_alloc_lru() or somehowmemcg_list_lru_alloc() failed to allocate list_lru_one() for a memcg butreturned success.  No evidence were found for these cases.Looking more deeply, we started seeing situations where valid memcg&#39;s idis not present in mem_cgroup_idr and in some cases multiple valid memcgshave same id and mem_cgroup_idr is pointing to one of them.  So, the mostreasonable explanation is that these situations can happen due to racebetween multiple idr_remove() calls or race betweenidr_alloc()/idr_replace() and idr_remove().  These races are causingmultiple memcgs to acquire the same ID and then offlining of one of themwould cleanup list_lrus on the system for all of them.  Later access fromother memcgs to the list_lru cause crashes due to missing list_lru_one.(CVE-2024-43892)In the Linux kernel, the following vulnerability has been resolved:serial: core: check uartclk for zero to avoid divide by zeroCalling ioctl TIOCSSERIAL with an invalid baud_base canresult in uartclk being zero, which will result in adivide by zero error in uart_get_divisor(). The check foruartclk being zero in uart_set_info() needs to be donebefore other settings are made as subsequent calls toioctl TIOCSSERIAL for the same port would be impacted ifthe uartclk check was done where uartclk gets set.Oops: divide error: 0000  PREEMPT SMP KASAN PTIRIP: 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-2024-43893)In the Linux kernel, the following vulnerability has been resolved:fou: remove warn in gue_gro_receive on unsupported protocolDrop the WARN_ON_ONCE inn gue_gro_receive if the encapsulated type isnot known or does not have a GRO handler.Such a packet is easily constructed. Syzbot generates them and setsoff this warning.Remove the warning as it is expected and not actionable.The warning was previously reduced from WARN_ON to WARN_ON_ONCE incommit 270136613bf7 (&#34;fou: Do WARN_ON_ONCE in gue_gro_receive for badproto callbacks&#34;).(CVE-2024-44940)In the Linux kernel, the following vulnerability has been resolved:atm: idt77252: prevent use after free in dequeue_rx()We can&#39;t dereference &#34;skb&#34; after calling vcc-&gt;push() because the skbis released.(CVE-2024-44998)In the Linux kernel, the following vulnerability has been resolved:xhci: Fix Panther point NULL pointer deref at full-speed re-enumerationre-enumerating full-speed devices after a failed address device commandcan trigger a NULL pointer dereference.Full-speed devices may need to reconfigure the endpoint 0 Max Packet Sizevalue during enumeration. Usb core calls usb_ep0_reinit() in this case,which ends up calling xhci_configure_endpoint().On Panther point xHC the xhci_configure_endpoint() function willadditionally check and reserve bandwidth in software. Other hosts dothis in hardwareIf xHC address device command fails then a new xhci_virt_device structureis allocated as part of re-enabling the slot, but the bandwidth tablepointers are not set up properly here.This triggers the NULL pointer dereference the next time usb_ep0_reinit()is called and xhci_configure_endpoint() tries to check and reservebandwidth[46710.713538] usb 3-1: new full-speed USB device number 5 using xhci_hcd[46710.713699] usb 3-1: Device not responding to setup address.[46710.917684] usb 3-1: Device not responding to setup address.[46711.125536] usb 3-1: device not accepting address 5, error -71[46711.125594] BUG: kernel NULL pointer dereference, address: 0000000000000008[46711.125600] #PF: supervisor read access in kernel mode[46711.125603] #PF: error_code(0x0000) - not-present page[46711.125606] PGD 0 P4D 0[46711.125610] Oops: Oops: 0000 [#1] PREEMPT SMP PTI[46711.125615] CPU: 1 PID: 25760 Comm: kworker/1:2 Not tainted 6.10.3_2 #1[46711.125620] Hardware name: Gigabyte Technology Co., Ltd.[46711.125623] Workqueue: usb_hub_wq hub_event [usbcore][46711.125668] RIP: 0010:xhci_reserve_bandwidth (drivers/usb/host/xhci.cFix this by making sure bandwidth table pointers are set up correctlyafter a failed address device command, and additionally by avoidingchecking for bandwidth in cases like this where no actual endpoints areadded or removed, i.e. only context for default control endpoint 0 isevaluated.(CVE-2024-45006)In the Linux kernel, the following vulnerability has been resolved:s390/dasd: fix error recovery leading to data corruption on ESE devicesExtent Space Efficient (ESE) or thin provisioned volumes need to beformatted on demand during usual IO processing.The dasd_ese_needs_format function checks for error codes that signalthe non existence of a proper track format.The check for incorrect length is to imprecise since other error casesleading to transport of insufficient data also have this flag set.This might lead to data corruption in certain error cases for exampleduring a storage server warmstart.Fix by removing the check for incorrect length and replacing byexplicitly checking for invalid track format in transport mode.Also remove the check for file protected since this is not a validESE handling case.(CVE-2024-45026)In the Linux kernel, the following vulnerability has been resolved:nfc: pn533: Add poll mod list filling checkIn case of im_protocols value is 1 and tm_protocols value is 0 thiscombination successfully passes the check&#39;if (!im_protocols &amp;&amp; !tm_protocols)&#39; in the nfc_start_poll().But then after pn533_poll_create_mod_list() call in pn533_start_poll()poll mod list will remain empty and dev-&gt;poll_mod_count will remain 0which lead to division by zero.Normally no im protocol has value 1 in the mask, so this combination isnot expected by driver. But these protocol values actually come fromuserspace via Netlink interface (NFC_CMD_START_POLL operation). So abroken or malicious program may pass a message containing a &#34;bad&#34;combination of protocol parameter values so that dev-&gt;poll_mod_countis not incremented inside pn533_poll_create_mod_list(), thus leadingto division by zero.Call trace looks like:nfc_genl_start_poll()  nfc_start_poll()    -&gt;start_poll()    pn533_start_poll()Add poll mod list filling check.Found by Linux Verification Center (linuxtesting.org) with SVACE.(CVE-2024-46676)In the Linux kernel, the following vulnerability has been resolved:usb: typec: ucsi: Fix null pointer dereference in traceucsi_register_altmode checks IS_ERR for the alt pointer and treatsNULL as valid. When CONFIG_TYPEC_DP_ALTMODE is not enabled,ucsi_register_displayport returns NULL which causes a NULL pointerdereference in trace. Rather than return NULL, calltypec_port_register_altmode to register DisplayPort alternate modeas a non-controllable mode when CONFIG_TYPEC_DP_ALTMODE is not enabled.(CVE-2024-46719)In the Linux kernel, the following vulnerability has been resolved:bpf: Remove tst_run from lwt_seg6local_prog_ops.The syzbot reported that the lwt_seg6 related BPF ops can be invokedvia bpf_test_run() without without entering input_action_end_bpf()first.Martin KaFai Lau said that self test for BPF_PROG_TYPE_LWT_SEG6LOCALprobably didn&#39;t work since it was introduced in commit 04d4b274e2a(&#34;ipv6: sr: Add seg6local action End.BPF&#34;). The reason is that theper-CPU variable seg6_bpf_srh_states::srh is never assigned in the selftest case but each BPF function expects it.Remove test_run for BPF_PROG_TYPE_LWT_SEG6LOCAL.(CVE-2024-46754)In the Linux kernel, the following vulnerability has been resolved:ice: Add netif_device_attach/detach into PF reset flowEthtool callbacks can be executed while reset is in progress and try toaccess deleted resources, e.g. getting coalesce settings can result in aNULL pointer dereference seen below.Reproduction steps:Once the driver is fully initialized, trigger reset:&#x9;# echo 1 &gt; /sys/class/net/&lt;interface&gt;/device/resetwhen reset is in progress try to get coalesce settings using ethtool:&#x9;# ethtool -c &lt;interface&gt;BUG: kernel NULL pointer dereference, address: 0000000000000020PGD 0 P4D 0Oops: Oops: 0000 [#1] PREEMPT SMP PTICPU: 11 PID: 19713 Comm: ethtool Tainted: G S                 6.10.0-rc7+ #7RIP: 0010:ice_get_q_coalesce+0x2e/0xa0 [ice]RSP: 0018:ffffbab1e9bcf6a8 EFLAGS: 00010206RAX: 000000000000000c RBX: ffff94512305b028 RCX: 0000000000000000RDX: 0000000000000000 RSI: ffff9451c3f2e588 RDI: ffff9451c3f2e588RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000R10: ffff9451c3f2e580 R11: 000000000000001f R12: ffff945121fa9000R13: ffffbab1e9bcf760 R14: 0000000000000013 R15: ffffffff9e65dd40FS:  00007faee5fbe740(0000) GS:ffff94546fd80000(0000) knlGS:0000000000000000CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033CR2: 0000000000000020 CR3: 0000000106c2e005 CR4: 00000000001706f0Call Trace:&lt;TASK&gt;ice_get_coalesce+0x17/0x30 [ice]coalesce_prepare_data+0x61/0x80ethnl_default_doit+0xde/0x340genl_family_rcv_msg_doit+0xf2/0x150genl_rcv_msg+0x1b3/0x2c0netlink_rcv_skb+0x5b/0x110genl_rcv+0x28/0x40netlink_unicast+0x19c/0x290netlink_sendmsg+0x222/0x490__sys_sendto+0x1df/0x1f0__x64_sys_sendto+0x24/0x30do_syscall_64+0x82/0x160entry_SYSCALL_64_after_hwframe+0x76/0x7eRIP: 0033:0x7faee60d8e27Calling netif_device_detach() before reset makes the net core not callthe driver when ethtool command is issued, the attempt to execute anethtool command during reset will result in the following message:    netlink error: No such deviceinstead of NULL pointer dereference. Once reset is done andice_rebuild() is executing, the netif_device_attach() is called to allowfor ethtool operations to occur again in a safe manner.(CVE-2024-46770)In the Linux kernel, the following vulnerability has been resolved:ksmbd: unset the binding mark of a reused connectionSteve French reported null pointer dereference error from sha256 lib.cifs.ko can send session setup requests on reused connection.If reused connection is used for binding session, conn-&gt;binding canstill remain true and generate_preauth_hash() will not setsess-&gt;Preauth_HashValue and it will be NULL.It is used as a material to create an encryption key inksmbd_gen_smb311_encryptionkey. -&gt;Preauth_HashValue cause null pointerdereference error from crypto_shash_update().BUG: kernel NULL pointer dereference, address: 0000000000000000#PF: supervisor read access in kernel mode#PF: error_code(0x0000) - not-present pagePGD 0 P4D 0Oops: 0000 [#1] PREEMPT SMP PTICPU: 8 PID: 429254 Comm: kworker/8:39Hardware name: LENOVO 20MAS08500/20MAS08500, BIOS N2CET69W (1.52 )Workqueue: ksmbd-io handle_ksmbd_work [ksmbd]RIP: 0010:lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]&lt;TASK&gt;? show_regs+0x6d/0x80? __die+0x24/0x80? page_fault_oops+0x99/0x1b0? do_user_addr_fault+0x2ee/0x6b0? exc_page_fault+0x83/0x1b0? asm_exc_page_fault+0x27/0x30? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]? lib_sha256_base_do_update.isra.0+0x11e/0x1d0 [sha256_ssse3]? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]? __pfx_sha256_transform_rorx+0x10/0x10 [sha256_ssse3]_sha256_update+0x77/0xa0 [sha256_ssse3]sha256_avx2_update+0x15/0x30 [sha256_ssse3]crypto_shash_update+0x1e/0x40hmac_update+0x12/0x20crypto_shash_update+0x1e/0x40generate_key+0x234/0x380 [ksmbd]generate_smb3encryptionkey+0x40/0x1c0 [ksmbd]ksmbd_gen_smb311_encryptionkey+0x72/0xa0 [ksmbd]ntlm_authenticate.isra.0+0x423/0x5d0 [ksmbd]smb2_sess_setup+0x952/0xaa0 [ksmbd]__process_request+0xa3/0x1d0 [ksmbd]__handle_ksmbd_work+0x1c4/0x2f0 [ksmbd]handle_ksmbd_work+0x2d/0xa0 [ksmbd]process_one_work+0x16c/0x350worker_thread+0x306/0x440? __pfx_worker_thread+0x10/0x10kthread+0xef/0x120? __pfx_kthread+0x10/0x10ret_from_fork+0x44/0x70? __pfx_kthread+0x10/0x10ret_from_fork_asm+0x1b/0x30&lt;/TASK&gt;(CVE-2024-46795)In the Linux kernel, the following vulnerability has been resolved:drm/amdgpu: the warning dereferencing obj for nbio_v7_4if ras_manager obj null, don&#39;t print NBIO err data(CVE-2024-46819)In the Linux kernel, the following vulnerability has been resolved:sched: sch_cake: fix bulk flow accounting logic for host fairnessIn sch_cake, we keep track of the count of active bulk flows per host,when running in dst/src host fairness mode, which is used as theround-robin weight when iterating through flows. The count of activebulk flows is updated whenever a flow changes state.This has a peculiar interaction with the hash collision handling: when ahash collision occurs (after the set-associative hashing), the state ofthe hash bucket is simply updated to match the new packet that collided,and if host fairness is enabled, that also means assigning new per-hoststate to the flow. For this reason, the bulk flow counters of thehost(s) assigned to the flow are decremented, before new state isassigned (and the counters, which may not belong to the same hostanymore, are incremented again).Back when this code was introduced, the host fairness mode was alwaysenabled, so the decrement was unconditional. When the configurationflags were introduced the *increment* was made conditional, butthe *decrement* was not. Which of course can lead to a spuriousdecrement (and associated wrap-around to U16_MAX).AFAICT, when host fairness is disabled, the decrement and wrap-aroundhappens as soon as a hash collision occurs (which is not that common initself, due to the set-associative hashing). However, in most cases thisis harmless, as the value is only used when host fairness mode isenabled. So in order to trigger an array overflow, sch_cake has to firstbe configured with host fairness disabled, and while running in thismode, a hash collision has to occur to cause the overflow. Then, theqdisc has to be reconfigured to enable host fairness, which leads to thearray out-of-bounds because the wrapped-around value is retained andused as an array index. It seems that syzbot managed to trigger this,which is quite impressive in its own right.This patch fixes the issue by introducing the same conditional check ondecrement as is used on increment.The original bug predates the upstreaming of cake, but the commit listedin the Fixes tag touched that code, meaning that this patch won&#39;t applybefore that.(CVE-2024-46828)In the Linux kernel, the following vulnerability has been resolved:btrfs: clean up our handling of refs == 0 in snapshot deleteIn reada we BUG_ON(refs == 0), which could be unkind since we aren&#39;tholding a lock on the extent leaf and thus could get a transientincorrect answer.  In walk_down_proc we also BUG_ON(refs == 0), whichcould happen if we have extent tree corruption.  Change that to return-EUCLEAN.  In do_walk_down() we catch this case and handle it correctly,however we return -EIO, which -EUCLEAN is a more appropriate error code.Finally in walk_up_proc we have the same BUG_ON(refs == 0), so convertthat to proper error handling.  Also adjust the error message so we canactually do something with the information.(CVE-2024-46840)In the Linux kernel, the following vulnerability has been resolved:perf/x86/intel: Limit the period on HaswellRunning the ltp test cve-2015-3290 concurrently reports the followingwarnings.perfevents: irq loop stuck!  WARNING: CPU: 31 PID: 32438 at arch/x86/events/intel/core.c:3174  intel_pmu_handle_irq+0x285/0x370  Call Trace:   &lt;NMI&gt;   ? __warn+0xa4/0x220   ? intel_pmu_handle_irq+0x285/0x370   ? __report_bug+0x123/0x130   ? intel_pmu_handle_irq+0x285/0x370   ? __report_bug+0x123/0x130   ? intel_pmu_handle_irq+0x285/0x370   ? report_bug+0x3e/0xa0   ? handle_bug+0x3c/0x70   ? exc_invalid_op+0x18/0x50   ? asm_exc_invalid_op+0x1a/0x20   ? irq_work_claim+0x1e/0x40   ? intel_pmu_handle_irq+0x285/0x370   perf_event_nmi_handler+0x3d/0x60   nmi_handle+0x104/0x330Thanks to Thomas Gleixner&#39;s analysis, the issue is caused by the lowinitial period (1) of the frequency estimation algorithm, which triggersthe defects of the HW, specifically erratum HSW11 and HSW143. (For thedetails, please refer https://lore.kernel.org/lkml/87plq9l5d2.ffs@tglx/)The HSW11 requires a period larger than 100 for the INST_RETIRED.ALLevent, but the initial period in the freq mode is 1. The erratum is thesame as the BDM11, which has been supported in the kernel. A minimumperiod of 128 is enforced as well on HSW.HSW143 is regarding that the fixed counter 1 may overcount 32 with theHyper-Threading is enabled. However, based on the test, the hardwarehas more issues than it tells. Besides the fixed counter 1, the message&#39;interrupt took too long&#39; can be observed on any counter which was armedwith a period &lt; 32 and two events expired in the same NMI. A minimumperiod of 32 is enforced for the rest of the events.The recommended workaround code of the HSW143 is not implemented.Because it only addresses the issue for the fixed counter. It bringsextra overhead through extra MSR writing. No related overcounting issuehas been reported so far.(CVE-2024-46848)In the Linux kernel, the following vulnerability has been resolved:net: dpaa: Pad packets to ETH_ZLENWhen sending packets under 60 bytes, up to three bytes of the bufferfollowing the data may be leaked. Avoid this by extending all packets toETH_ZLEN, ensuring nothing is leaked in the padding. This bug can bereproduced by running&#x9;$ ping -s 11 destination(CVE-2024-46854)In the Linux kernel, the following vulnerability has been resolved:netfilter: nft_socket: fix sk refcount leaksWe must put &#39;sk&#39; reference before returning.(CVE-2024-46855)In the Linux kernel, the following vulnerability has been resolved:mptcp: pm: Fix uaf in __timer_delete_syncThere are two paths to access mptcp_pm_del_add_timer, result in a racecondition:     CPU1&#x9;&#x9;&#x9;&#x9;CPU2     ====                               ====     net_rx_action     napi_poll                          netlink_sendmsg     __napi_poll                        netlink_unicast     process_backlog                    netlink_unicast_kernel     __netif_receive_skb                genl_rcv     __netif_receive_skb_one_core       netlink_rcv_skb     NF_HOOK                            genl_rcv_msg     ip_local_deliver_finish            genl_family_rcv_msg     ip_protocol_deliver_rcu            genl_family_rcv_msg_doit     tcp_v4_rcv                         mptcp_pm_nl_flush_addrs_doit     tcp_v4_do_rcv                      mptcp_nl_remove_addrs_list     tcp_rcv_established                mptcp_pm_remove_addrs_and_subflows     tcp_data_queue                     remove_anno_list_by_saddr     mptcp_incoming_options             mptcp_pm_del_add_timer     mptcp_pm_del_add_timer             kfree(entry)In remove_anno_list_by_saddr(running on CPU2), after leaving the criticalzone protected by &#34;pm.lock&#34;, the entry will be released, which leads to theoccurrence of uaf in the mptcp_pm_del_add_timer(running on CPU1).Keeping a reference to add_timer inside the lock, and callingsk_stop_timer_sync() with this reference, instead of &#34;entry-&gt;add_timer&#34;.Move list_del(&amp;entry-&gt;list) to mptcp_pm_del_add_timer and inside the pm lock,do not directly access any members of the entry outside the pm lock, whichcan avoid similar &#34;entry-&gt;x&#34; uaf.(CVE-2024-46858)In the Linux kernel, the following vulnerability has been resolved:crypto: stm32/cryp - call finalize with bh disabledThe finalize operation in interrupt mode produce a produces a spinlockrecursion warning. The reason is the fact that BH must be disabledduring this process.(CVE-2024-47658)In the Linux kernel, the following vulnerability has been resolved:spi: hisi-kunpeng: Add verification for the max_frequency provided by the firmwareIf the value of max_speed_hz is 0, it may cause a division by zeroerror in hisi_calc_effective_speed().The value of max_speed_hz is provided by firmware.Firmware is generally considered as a trusted domain. However, asdivision by zero errors can cause system failure, for defense measure,the value of max_speed is validated here. So 0 is regarded as invalidand an error code is returned.(CVE-2024-47664)In the Linux kernel, the following vulnerability has been resolved:ocfs2: add bounds checking to ocfs2_xattr_find_entry()Add a paranoia check to make sure it doesn&#39;t stray beyond valid memoryregion containing ocfs2 xattr entries when scanning for a match.  It willprevent out-of-bound access in case of crafted images.(CVE-2024-47670)In the Linux kernel, the following vulnerability has been resolved:USB: usbtmc: prevent kernel-usb-infoleakThe syzbot reported a kernel-usb-infoleak in usbtmc_write,we need to clear the structure before filling fields.(CVE-2024-47671)In the Linux kernel, the following vulnerability has been resolved:wifi: iwlwifi: mvm: don&#39;t wait for tx queues if firmware is deadThere is a WARNING in iwl_trans_wait_tx_queues_empty() (that wasrecently converted from just a message), that can be hit if wewait for TX queues to become empty after firmware died. Clearly,we can&#39;t expect anything from the firmware after it&#39;s declared dead.Don&#39;t call iwl_trans_wait_tx_queues_empty() in this case. While it couldbe a good idea to stop the flow earlier, the flush functions do somemaintenance work that is not related to the firmware, so keep that partof the code running even when the firmware is not running.[edit commit message](CVE-2024-47672)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="kernel" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debuginfo" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-debugsource" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-devel" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-headers" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-source" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-debuginfo" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="kernel-tools-devel" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="perf-debuginfo" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-perf-debuginfo" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debuginfo" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-debugsource" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-debugsource-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-devel" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-devel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-headers" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-headers-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-source" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-source-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-debuginfo" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="kernel-tools-devel" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>kernel-tools-devel-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>perf-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="perf-debuginfo" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-perf-debuginfo" release="136.97.0.178.oe2203sp1" version="5.10.0">
                         <filename>python3-perf-debuginfo-5.10.0-136.97.0.178.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2260</id>
          <title>An update for grafana is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2022-39229" id="CVE-2022-39229" title="CVE-2022-39229" type="cve"></reference>
          </references>
          <description>Grafana is an open source data visualization platform for metrics, logs, and traces. Versions prior to 9.1.8 and 8.5.14 allow one user to block another user&#39;s login attempt by registering someone else&#39;e email address as a username. A Grafana user’s username and email address are unique fields, that means no other user can have the same username or email address as another user. A user can have an email address as a username. However, the login system allows users to log in with either username or email address. Since Grafana allows a user to log in with either their username or email address, this creates an usual behavior where `user_1` can register with one email address and `user_2` can register their username as `user_1`’s email address. This prevents `user_1` logging into the application since `user_1`&#39;s password won’t match with `user_2`&#39;s email address. Versions 9.1.8 and 8.5.14 contain a patch. There are no workarounds for this issue.(CVE-2022-39229)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="grafana" release="7.oe2203sp1" version="7.5.15">
                         <filename>grafana-7.5.15-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="grafana-debuginfo" release="7.oe2203sp1" version="7.5.15">
                         <filename>grafana-debuginfo-7.5.15-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana" release="7.oe2203sp1" version="7.5.15">
                         <filename>grafana-7.5.15-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="grafana-debuginfo" release="7.oe2203sp1" version="7.5.15">
                         <filename>grafana-debuginfo-7.5.15-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2261</id>
          <title>An update for xorg-x11-server is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-5574" id="CVE-2023-5574" title="CVE-2023-5574" type="cve"></reference>
          </references>
          <description>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)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="xorg-x11-server" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xdmx" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xephyr" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xnest" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-Xvfb" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-common" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debuginfo" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-debugsource" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="xorg-x11-server-devel" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-32.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-help" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-help-1.20.11-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="xorg-x11-server-source" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-source-1.20.11-32.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xdmx" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xdmx-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xephyr" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xephyr-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xnest" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xnest-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-Xvfb" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-Xvfb-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-common" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-common-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debuginfo" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debuginfo-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-debugsource" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-debugsource-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="xorg-x11-server-devel" release="32.oe2203sp1" version="1.20.11">
                         <filename>xorg-x11-server-devel-1.20.11-32.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2264</id>
          <title>An update for gnutls is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-28835" id="CVE-2024-28835" title="CVE-2024-28835" type="cve"></reference>
          </references>
          <description>A flaw has been discovered in GnuTLS where an application crash can be induced when attempting to verify a specially crafted .pem bundle using the &#34;certtool --verify-chain&#34; command.(CVE-2024-28835)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="gnutls" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debuginfo" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-debugsource" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-devel" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="gnutls-utils" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-14.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="gnutls-help" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-help-3.7.2-14.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debuginfo" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debuginfo-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-debugsource" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-debugsource-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-devel" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-devel-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="gnutls-utils" release="14.oe2203sp1" version="3.7.2">
                         <filename>gnutls-utils-3.7.2-14.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2265</id>
          <title>An update for edk2 is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-38796" id="CVE-2024-38796" title="CVE-2024-38796" type="cve"></reference>
          </references>
          <description>EDK2 contains a vulnerability in the PeCoffLoaderRelocateImage(). An Attacker may cause memory corruption due to an overflow via an adjacent network. A successful exploit of this vulnerability may lead to a loss of Confidentiality, Integrity, and/or Availability.(CVE-2024-38796)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="edk2-debuginfo" release="21.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-debugsource" release="21.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="edk2-devel" release="21.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-21.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-aarch64" release="21.oe2203sp1" version="202011">
                         <filename>edk2-aarch64-202011-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-help" release="21.oe2203sp1" version="202011">
                         <filename>edk2-help-202011-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="edk2-ovmf" release="21.oe2203sp1" version="202011">
                         <filename>edk2-ovmf-202011-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-edk2-devel" release="21.oe2203sp1" version="202011">
                         <filename>python3-edk2-devel-202011-21.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debuginfo" release="21.oe2203sp1" version="202011">
                         <filename>edk2-debuginfo-202011-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-debugsource" release="21.oe2203sp1" version="202011">
                         <filename>edk2-debugsource-202011-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="edk2-devel" release="21.oe2203sp1" version="202011">
                         <filename>edk2-devel-202011-21.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2266</id>
          <title>An update for unbound is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8508" id="CVE-2024-8508" title="CVE-2024-8508" type="cve"></reference>
          </references>
          <description>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-8508)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="python3-unbound" release="15.oe2203sp1" version="1.13.2">
                         <filename>python3-unbound-1.13.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-1.13.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debuginfo" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-debugsource" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-devel" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-devel-1.13.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-help" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-help-1.13.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="unbound-libs" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-libs-1.13.2-15.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-unbound" release="15.oe2203sp1" version="1.13.2">
                         <filename>python3-unbound-1.13.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-1.13.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debuginfo" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-debuginfo-1.13.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-debugsource" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-debugsource-1.13.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-devel" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-devel-1.13.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-help" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-help-1.13.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="unbound-libs" release="15.oe2203sp1" version="1.13.2">
                         <filename>unbound-libs-1.13.2-15.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2267</id>
          <title>An update for qemu is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Low</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-8612" id="CVE-2024-8612" title="CVE-2024-8612" type="cve"></reference>
          </references>
          <description>A flaw was found in QEMU, in the virtio-scsi, virtio-blk, and virtio-crypto devices. The size for virtqueue_push as set in virtio_scsi_complete_req / virtio_blk_req_complete / virito_crypto_req_complete could be larger than the true size of the data which has been sent to guest. Once virtqueue_push() finally calls dma_memory_unmap to ummap the in_iov, it may call the address_space_write function to write back the data. Some uninitialized data may exist in the bounce.buffer, leading to an information leak.(CVE-2024-8612)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="qemu" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-block-curl" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-block-iscsi" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-block-rbd" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-block-ssh" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-debuginfo" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-debugsource" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-guest-agent" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-hw-usb-host" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-img" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-system-aarch64" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-system-arm" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-system-riscv" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="qemu-system-x86_64" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-100.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="qemu-help" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-help-6.2.0-100.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-block-curl" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-curl-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-block-iscsi" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-iscsi-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-block-rbd" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-rbd-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-block-ssh" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-block-ssh-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-debuginfo" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-debuginfo-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-debugsource" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-debugsource-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-guest-agent" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-guest-agent-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-hw-usb-host" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-hw-usb-host-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-img" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-img-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-seabios" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-seabios-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-system-aarch64" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-aarch64-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-system-arm" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-arm-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-system-riscv" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-riscv-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="qemu-system-x86_64" release="100.oe2203sp1" version="6.2.0">
                         <filename>qemu-system-x86_64-6.2.0-100.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2269</id>
          <title>An update for redis is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2023-45145" id="CVE-2023-45145" title="CVE-2023-45145" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31228" id="CVE-2024-31228" title="CVE-2024-31228" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-31449" id="CVE-2024-31449" title="CVE-2024-31449" type="cve"></reference>
          </references>
          <description>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.(CVE-2023-45145)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-31228)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.(CVE-2024-31449)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="redis" release="7.oe2203sp1" version="4.0.14">
                         <filename>redis-4.0.14-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debuginfo" release="7.oe2203sp1" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="redis-debugsource" release="7.oe2203sp1" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-7.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis" release="7.oe2203sp1" version="4.0.14">
                         <filename>redis-4.0.14-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debuginfo" release="7.oe2203sp1" version="4.0.14">
                         <filename>redis-debuginfo-4.0.14-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="redis-debugsource" release="7.oe2203sp1" version="4.0.14">
                         <filename>redis-debugsource-4.0.14-7.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2276</id>
          <title>An update for libyaml is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-3205" id="CVE-2024-3205" title="CVE-2024-3205" type="cve"></reference>
          </references>
          <description>Rejected reason: ** 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: The maintainer identified an error in the libyaml fuzzers. It is not possible to reproduce nor exploit the issue.(CVE-2024-3205)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="libyaml" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-0.2.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libyaml-debuginfo" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-debuginfo-0.2.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libyaml-debugsource" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-debugsource-0.2.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="libyaml-devel" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-devel-0.2.5-6.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="libyaml-help" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-help-0.2.5-6.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libyaml" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-0.2.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libyaml-debuginfo" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-debuginfo-0.2.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libyaml-debugsource" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-debugsource-0.2.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="libyaml-devel" release="6.oe2203sp1" version="0.2.5">
                         <filename>libyaml-devel-0.2.5-6.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2281</id>
          <title>An update for python-django is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Important</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45230" id="CVE-2024-45230" title="CVE-2024-45230" type="cve"></reference>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-45231" id="CVE-2024-45231" title="CVE-2024-45231" type="cve"></reference>
          </references>
          <description>An issue was discovered in Django 5.1 before 5.1.1, 5.0 before 5.0.9, and 4.2 before 4.2.16. The urlize() and urlizetrunc() template filters are subject to a potential denial-of-service attack via very large inputs with a specific sequence of characters.(CVE-2024-45230)An issue was discovered in Django v5.1.1, v5.0.9, and v4.2.16. The django.contrib.auth.forms.PasswordResetForm class, when used in a view implementing password reset flows, allows remote attackers to enumerate user e-mail addresses by sending password reset requests and observing the outcome (only when e-mail sending is consistently failing).(CVE-2024-45231)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="noarch" name="python-django-help" release="2.oe2203sp1" version="4.2.15">
                         <filename>python-django-help-4.2.15-2.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="noarch" name="python3-Django" release="2.oe2203sp1" version="4.2.15">
                         <filename>python3-Django-4.2.15-2.oe2203sp1.noarch.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
     <update from="openeuler.org" type="security" status="stable">
          <id>openEuler-SA-2024-2284</id>
          <title>An update for OpenIPMI is now available for openEuler-22.03-LTS-SP1</title>
          <severity>Moderate</severity>
          <release>openEuler</release>
          <issued date="2024-10-18"></issued>
          <references>
               <reference href="https://nvd.nist.gov/vuln/detail/CVE-2024-42934" id="CVE-2024-42934" title="CVE-2024-42934" type="cve"></reference>
          </references>
          <description>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.(CVE-2024-42934)</description>
          <pkglist>
               <collection>
                    <name>openEuler</name>
                    <package arch="aarch64" name="OpenIPMI" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-2.0.32-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenIPMI-debuginfo" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-debuginfo-2.0.32-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenIPMI-debugsource" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-debugsource-2.0.32-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenIPMI-devel" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-devel-2.0.32-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="OpenIPMI-perl" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-perl-2.0.32-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="aarch64" name="python3-openipmi" release="4.oe2203sp1" version="2.0.32">
                         <filename>python3-openipmi-2.0.32-4.oe2203sp1.aarch64.rpm</filename>
                    </package>
                    <package arch="noarch" name="OpenIPMI-help" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-help-2.0.32-4.oe2203sp1.noarch.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-2.0.32-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI-debuginfo" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-debuginfo-2.0.32-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI-debugsource" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-debugsource-2.0.32-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI-devel" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-devel-2.0.32-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="OpenIPMI-perl" release="4.oe2203sp1" version="2.0.32">
                         <filename>OpenIPMI-perl-2.0.32-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
                    <package arch="x86_64" name="python3-openipmi" release="4.oe2203sp1" version="2.0.32">
                         <filename>python3-openipmi-2.0.32-4.oe2203sp1.x86_64.rpm</filename>
                    </package>
               </collection>
          </pkglist>
     </update>
</updates>